Windows 7和Windows 8中有计时器合并支持，例如请参阅：Timer coalescing in .net
Windows 7有一个函数SetWaitableTimerEx，声称它支持合并here和here。
Windows 8还有一个函数SetCoalescableTimer，支持根据MSDN进行合并。
左右，在Windows 7和Windows 8中有很多关于计时器合并的讨论。但似乎它可能已经在早些时候实现过了。是这样吗？
首先，SetThreadpoolTimer available since Vista在Vista下提供计时器合并是否正确。或者它是否只提供接口并且实际上仅在Windows 7之后实现合并？
从"Thread Pool Timers and I/O"我可以看到
“这实际上是影响能效并有助于降低整体功耗的功能。它基于一种称为定时器合并的技术。”
对于支持SetThreadpoolTimer功能的所有Windows版本，该句子是否正确？
其次，现在我开始疑惑了。我可以看到timeSetEvent available since XP有一个名为uResolution的参数。在定时器事件等待的持续时间内，此参数是否仅更改全局定时器分辨率，如timeBeginPeriod，或仅影响此特定定时器，还提供定时器合并？
最后，是否有任何其他或替代功能可在Windows XP或Vista下提供定时器合并功能？
答案 0 :(得分：4)
一般的几句话：
定时器合并提供了一种减少中断次数的方法。允许应用程序为其时序要求指定容差。这允许操作系统批量生产＃34;中断有几个后果：
Windows以及其他基于中断的操作系统始终是＆＃34;批处理＆＃34;定时活动。设置为在特定时间发生的任何事情都依赖于到期时间到期。因此，事件与中断合并。该方案的粒度由中断频率决定。必须阅读那些对计时器合并感兴趣的人：MSDN: Windows Timer Coalescing。
出于性能原因，应尽一切努力减少中断的数量
尽可能多。遗憾的是，许多软件包确实将系统定时器分辨率设置得很高，例通过多媒体计时器界面timeBeginPeriod / timeEndPeriod或底层API NtSetTimerResolution。就像汉斯提到的那样：＆＃34; Chrome＆＃34;这是一个很好的例子，说明如何夸大这些功能的使用。
其次，现在我开始想知道...... timeSetEvent是多媒体计时器功能之一。它使用引擎盖下的timeBeginPeriod。
它使用得很糟糕：它将系统计时器分辨率设置为与执行平台上可用的计时器分辨率内的 uResolution 相匹配。在 uDelay 的较大值上，它可以以低分辨率等待，直到它接近延迟的到期，然后才提高系统计时器分辨率，但它将整个等待时间的计时器分辨率设置为指定 uResolution 。这是痛苦的，因为知道高分辨率也适用于长时间延迟。但是，多媒体定时器功能不建议用于大延迟。但是反复设置分辨率也不好（参见下面的注释）。
关于timeSetEvent的摘要：这个函数根本没有做任何合并，反之亦然：它可选地增加了中断的数量;从这个意义上讲，它会将事件传播到更多的中断上，而且需要进行批量处理。它们。
SetThreadpoolTimer引入了＃34;批处理＆＃34;第一次举办活动。由于对Windows笔记本电脑上的电池续航时间越来越多的抱怨，这主要是强制性的。 SetWaitableTimerEx进一步推动了该策略，SetCoalescableTimer是访问合并计时器的最新API。后者引入了值得思考的TIMERV_DEFAULT_COALESCING和TIMERV_NO_COALESCING，因为它们允许忽略某些事实。
借此机会获得有关系统计时器分辨率的一些注意事项：
更改系统定时器分辨率比仅增加中断频率更具有后果。使用timeBeginPeriod / NtSetTimerResolution时会产生一些影响：
SetSystemTimeAdjustment）第3点部分由Windows 7和Point 4处理。仅用Window 8.1解决。
系统时间的打嗝可以与支持的最小定时器分辨率（典型系统上为15.625 ms）一样大，并且经常在timeBeginPeriod / NtSetTimerResolution时累积。当尝试调整系统时间以匹配NTP参考时，这可能会导致相当大的跳跃。 NTP客户端需要以高计时器分辨率运行，以便在Windows版本上运行时获得合理的准确度＆lt; Windows 8.
最后： Windows本身会在看到优势时更改系统计时器分辨率。支持的计时器分辨率的数量取决于底层硬件和Windows版本。可以通过逐渐调用timeBeginPeriod并随后调用NtQueryTimerResolution来扫描可用解决方案列表。一些受支持的决议可能是“不喜欢的”＃34;通过Windows在特定平台上进行修改，以更好地满足Windows的需求。示例：XP可能会更改＆＃34;用户设置＆＃34;在某些平台上短时间后分辨率为~4 ms至1 ms。特定的Windows版本＆lt; 8.1会在不可预测的时间更改定时器分辨率。
如果要求申请完全独立于这些人工制品，则必须自行获得最高的可用分辨率。这样，应用程序在系统范围内的分辨率占主导地位，并且它不必担心其他应用程序或操作系统更改计时器分辨率。更现代的平台确实支持0.5 ms的定时器分辨率。 timeBeginPeriod不允许获得此解决方案，NtSetTimerResolution。 Here我已经描述了如何使用NtSetTimerResolution来获得0.5 ms的分辨率。
在这样的条件下，功耗可能会提高，但这需要支付可靠分辨率的费用：现代硬件上下文切换的能源成本通常为0.05 mJ至0.2 mJ（有人估计全球总数）每年的上下文切换量？）。 Windows将线程量子（时间片）削减到大约。 2/3当定时器分辨率设置为最大值时。因此，功耗提高了大约。 30％！