国庆无聊，写个高精度的定时器打发下时间，顺便散点分,该怎么解决
国庆无聊，写个高精度的定时器打发下时间，顺便散点分
一个可重用定时器类，能实现微秒级的定时，欢迎拍砖
http://blog.csdn.net/supconsupcon/archive/2009/10/05/4633482.aspx
------解决方案--------------------
个人认为这种所谓的高性能定时器好处多于害处，原因为：
1。多任务系统中，你的线程的时间不完全收你控制，只要有高优先级的认为存在，你的代码永远没有机会被执行，也不可能准确。即使没有高优先级的认为存在，只要和你同优先级的线程足够忙，估计你也很难达到精度（除非线程切换速度远远高于你的时间间隔）
2。采用死循环式的轮询是多任务系统的大忌，无论你线程是否该工作了，他都占据CPU，实际上这会让你系统永远很难合理的分配资源
------解决方案--------------------
UP
------解决方案--------------------
//一般不会在windows下搞什么高精度计时器。
//而在实时操作系统下也不需要这么复杂。
------------分割线----------------
//如果这些东西拿来练练手还是不错的
------解决方案--------------------
即使在unix下也应该尽量限制这种高精度的定时器，除非这是单任务系统
------解决方案--------------------
呵呵，鼓励人家一下嘛。
------解决方案--------------------
Windows不是一个高精度的系统，至少在应用层下
驱动下可以纳秒级
------解决方案--------------------
散分：20？还是我眼花少看了0？
------解决方案--------------------
很有技术含量…
------解决方案--------------------
接分
------解决方案--------------------
------解决方案--------------------
即使是微秒级的定时器，实际也达不到这个精度，无论Windows还是Linux都一样，定时器总需要回调吧，只要回调函数占用足够多的时间，定时器就不准了，这是没办法的事。
Windows已经有了高精度定时器了，比如视频播放虽然不需要微秒级的，但是需要10毫秒以下的，普通WM_TIMER达不到这个精度。除了多媒体时钟，我发现微软还有其它组件都提供了各自的高精度定时器实现，比如IE，比如TRANSFORM，不知道微软为何不统一。
------解决方案--------------------
好假，哪里是你写的啊。
------解决方案--------------------
过来看看
------解决方案--------------------
顶一下
------解决方案--------------------
呵呵
------解决方案--------------------
------解决方案--------------------
------解决方案--------------------
支持你散分的高强度行为 哈哈
------解决方案--------------------
dingxia
------解决方案--------------------
计时和定时是不同的概念。计时可以有很高的精度，定时却不可能
借助QueryPerformanceCount和QueryPerformanceFrequency可以得到很高的计时精度
或者借助RDTSC汇编指令读取CPU内部的一个极高精度的时间戳，可以较高精度的计时
定时却不行了，当你的定时器到时，要被唤醒的时候，你不会立刻得到运行，
要等其它进程的时间片耗尽让出CPU，然后完成把那个进程挂起和把你这个进程wakeup这两个过程
这两个过程涉及到很多操作，现场保护和现场恢复，优先级重新计算等等，本身就是要消耗一定的时间
如果这个消耗的时间大于你的定时器精度，那么定时器的误差就会比较大了。
最不幸的是，碰巧繁忙的进程比较多，排在你进程前面的进程又有很多，延迟个10秒执行都是有可能的
媒体播放器需要较高精度时间，但是也不会到微妙秒级，更加不会是纳秒级，一般毫秒级就够了
一个可重用定时器类，能实现微秒级的定时，欢迎拍砖
http://blog.csdn.net/supconsupcon/archive/2009/10/05/4633482.aspx
------解决方案--------------------
个人认为这种所谓的高性能定时器好处多于害处，原因为：
1。多任务系统中，你的线程的时间不完全收你控制，只要有高优先级的认为存在，你的代码永远没有机会被执行，也不可能准确。即使没有高优先级的认为存在，只要和你同优先级的线程足够忙，估计你也很难达到精度（除非线程切换速度远远高于你的时间间隔）
2。采用死循环式的轮询是多任务系统的大忌，无论你线程是否该工作了，他都占据CPU，实际上这会让你系统永远很难合理的分配资源
------解决方案--------------------
UP
------解决方案--------------------
//一般不会在windows下搞什么高精度计时器。
//而在实时操作系统下也不需要这么复杂。
------------分割线----------------
//如果这些东西拿来练练手还是不错的
------解决方案--------------------
即使在unix下也应该尽量限制这种高精度的定时器，除非这是单任务系统
------解决方案--------------------
呵呵，鼓励人家一下嘛。
------解决方案--------------------
Windows不是一个高精度的系统，至少在应用层下
驱动下可以纳秒级
------解决方案--------------------
散分：20？还是我眼花少看了0？
------解决方案--------------------
很有技术含量…
------解决方案--------------------
接分
------解决方案--------------------
------解决方案--------------------
即使是微秒级的定时器，实际也达不到这个精度，无论Windows还是Linux都一样，定时器总需要回调吧，只要回调函数占用足够多的时间，定时器就不准了，这是没办法的事。
Windows已经有了高精度定时器了，比如视频播放虽然不需要微秒级的，但是需要10毫秒以下的，普通WM_TIMER达不到这个精度。除了多媒体时钟，我发现微软还有其它组件都提供了各自的高精度定时器实现，比如IE，比如TRANSFORM，不知道微软为何不统一。
------解决方案--------------------
好假，哪里是你写的啊。
------解决方案--------------------
过来看看
------解决方案--------------------
顶一下
------解决方案--------------------
呵呵
------解决方案--------------------
------解决方案--------------------
------解决方案--------------------
支持你散分的高强度行为 哈哈
------解决方案--------------------
dingxia
------解决方案--------------------
计时和定时是不同的概念。计时可以有很高的精度，定时却不可能
借助QueryPerformanceCount和QueryPerformanceFrequency可以得到很高的计时精度
或者借助RDTSC汇编指令读取CPU内部的一个极高精度的时间戳，可以较高精度的计时
定时却不行了，当你的定时器到时，要被唤醒的时候，你不会立刻得到运行，
要等其它进程的时间片耗尽让出CPU，然后完成把那个进程挂起和把你这个进程wakeup这两个过程
这两个过程涉及到很多操作，现场保护和现场恢复，优先级重新计算等等，本身就是要消耗一定的时间
如果这个消耗的时间大于你的定时器精度，那么定时器的误差就会比较大了。
最不幸的是，碰巧繁忙的进程比较多，排在你进程前面的进程又有很多，延迟个10秒执行都是有可能的
媒体播放器需要较高精度时间，但是也不会到微妙秒级，更加不会是纳秒级，一般毫秒级就够了