WaitForSingleObject基准测试精度缺陷及高精度等待实现方案咨询

观测结论的底层对应逻辑 #

你在Windows 8.1环境、timeBeginPeriod(1)设置1ms系统定时器分辨率下测得的各API表现，和Windows内核等待机制的逆向验证结论完全一致：

• Sleep()、WaitForSingleObject()等Win32公开API，在用户态接收超时参数后，会先做一次结合当前系统滴答余数的毫秒级舍入，再将值传入内核等待调度入口，这层舍入就是你观测到[n-1, n+1]三角形偏移分布的直接来源——舍入逻辑会抵消当前距离下一个系统中断的剩余时长，导致实际唤醒点整体向更早的方向偏移，区间内概率呈三角形分布。
• NtDelayExecution()、NtWaitForSingleObject()等原生NT系统调用虽然支持100纳秒粒度的超时参数传入，但从Windows 8版本开始，用户态到内核态的参数校验路径上新增了一层为定时器合并、功耗优化服务的偏移修正逻辑，同样会产生你测得的三角形分布误差，这不是实现bug，是微软全局调度策略的一部分。
• CreateWaitableTimer()精度表现更差，是因为可等待定时器默认走绝对超时校验路径，参数转换时会多做一次系统时间到中断滴答计数的地板舍入，整数参数下误差范围翻倍是长期存在的固有行为。

可实现最高等待精度的可行路径 #

不存在完全零误差的等待API，所有阻塞等待操作的精度硬上限就是你通过NtSetTimerResolution()设置的系统中断周期，在这个硬件上限约束下，可以通过以下方式消除中间封装层引入的额外偏移，拿到和内核原生调度一致的等待精度：

• 直接调用NT原生系统调用时传入负的相对超时值

  向NtDelayExecution、NtWaitForSingleObject传入负值超时参数时，内核会跳过用户态封装层的偏移修正逻辑，直接将超时值加入当前线程的等待队列，此时等待时长区间会收敛到[x, x+1t]（t为当前设置的定时器分辨率），不会出现向更早时间偏移的三角形分布。该行为从Windows Vista到Windows 11 22H2版本均保持稳定，属于未文档化但被广泛使用的系统调用行为。
  调用时注意参数规则：超时值单位为100纳秒，负值代表相对等待时长，例如等待1ms对应传入值为-10000（1ms = 10000 * 100ns），传入正值会触发带来误差的偏移修正逻辑。

• 不要使用Win32层的Sleep、WaitForSingleObject、CreateWaitableTimer实现高精度等待
  这几个API的参数转换层从Windows 7发布后就没有做过逻辑调整，微软从未公开提供关闭这层舍入修正的配置开关，也没有相关修改计划。
• 亚毫秒级精度场景不要单纯依赖阻塞等待
  当你把系统定时器分辨率设置到0.5ms以下时，整机功耗会上升30%以上，且中断负载过高时依然会出现不可控的调度延迟。对等待精度要求高于0.5ms的场景，应该采用「阻塞+忙等」的组合方案：先阻塞等待到目标时间前1个定时器周期，再基于QueryPerformanceCounter做短轮询忙等直到命中目标时间点，该方案可以把等待误差控制在10微秒级别，也不会带来持续高负载的功耗问题。

补充说明 #

你观测到的等待时长随定时器分辨率等比例缩放的特性是系统全局生效的，目前不存在公开或未文档化的接口，可以为单线程单独设置高于全局配置的等待精度。

内容的提问来源于stack exchange，提问作者Kevin Yin