一个连续更新，高精度的时间供应器

核心提示： ...21:23:22.29621:23:22.29721:23:22.29721:23:22.29821:23:22.29821:23:22.29921:23:22.30021:23:22.30021:23:22.30121:23:22.30121:23:22.30221:23:22.3

...
21:23:22.296
21:23:22.297
21:23:22.297
21:23:22.298
21:23:22.298
21:23:22.299
21:23:22.300
21:23:22.300
21:23:22.301
21:23:22.301
21:23:22.302
21:23:22.302
21:23:22.303
...

尽管它看起来非常成功，但这个实现却有几个问题：同步实现（函数被命名为 "simplistic_synchronize"的一个很好的理由）；QueryPerformanceFrequency 报告的频率 ；系统时间变化缺乏保护。在接下来的章节中，我们会考虑这些问题的一些可能的改进。

实现同步的可靠方法

该同步实现没有考虑 Windows NT 调度器的抢先问题。例如，它无法保证在下面的两行代码之间不会发生线程上下文的切换，从而导致一个未知时间周期的延迟：

::GetSystemTimeAsFileTime(&ft1);
::QueryPerformanceCounter(&li);

大多时候只要满足下面的条件，这个过分单纯化的同步函数还是成功的：

当前线程不会被优先级更高的线程抢先进入就绪状态；

当前线程的时间片永远不会结束

很少有硬件中断（不同于时钟中断自身）

为此，最简明的解决方案是将进程的优先级提升为 REALTIME_PRIORITY_CLASS，将线程的优先级提升为 THREAD_PRIORITY_TIME_CRITICAL，从而阻止在同步期间线程被抢先。不幸的是，对于硬件中断你没有什么可做的，但行为良好的驱动程序应该处理它们的中断，排队延期的过程调用(deferred procedure call, DPC)，甚至以微秒级次序处理DPC。问题是你不能保证系统内所有驱动程序的行为都良好。事实上，即使在你系统里只有乖巧听话的驱动程序，你仍然会有许多中断。

上一页  1 2 3 4 5 6 7 8  下一页