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

核心提示： 尽管我们已经有了一个好的开端，仍有些问题需要解决，一个连续更新，高精度的时间供应器(5)，假设你及时在某些特定环节执行这个同步操作，然后，使用上的简单总是会增加复杂性和开销的，本文提供的下载例子中实现了用后台线程来同步性能计数器和系统时间，无论何时，只要你需要高精度的时间

尽管我们已经有了一个好的开端，仍有些问题需要解决。假设你及时在某些特定环节执行这个同步操作。然后，无论何时，只要你需要高精度的时间，就调用get_time。如早先讲述，QueryPerfomanceCounter 报告的频率被用于以高精度计算当前系统时间。由 get_time 报告的时间一定会同实际的时钟时间发生很大偏差的，得到一个比你所获得的精度大得多的值。这是因为性能计数器天生不是被用来计量长周期时间的。

我进行了一个小测试考察这个影响会有多大，以 2 微秒作为可接受的同步极限。（我选择 2 微秒是因为我的 双 PII 400HZ CPU 机子能得到最好结果），Figure 5 显示了这个结果。

Figure 5 同步测试

测试结果证明，仅在 110 秒后我的高精度时钟就偏离了实际系统时间1毫秒。速算一下表明性能计数器频率报告中存在一个大约百万分之九 的错误。一个0.000009的错误听起来很微小，但是如果你想报告一个微秒以下的时间这就是一个很大的冲击了。起初，我有两个想法。第一，用户负责定期的再同步，而且由此必须决定多长时间做一次。第二，同步由一个后台线程每n秒执行一次。

进行第一个想法的测试之前，我就决定反对它了。第二个想法似乎更加可行，我所能预见的唯一问题就是在客户端和同步线程之间的必须的同步会产生一些开销。使用上的简单总是会增加复杂性和开销的。

本文提供的下载例子中实现了用后台线程来同步性能计数器和系统时间。Figure 6 解释了这个实现如何设法让自己同实际系统时间保持接近（注意纵坐标现在被设为+/-100微秒）。

Figure 6　同步例子