Windows系统下Semaphore信号量延迟远低于预期的原因是什么

结论 #

你对Semaphore的工作原理理解存在误区，测量结果本身符合Windows平台的实际表现，测量代码没有原则性错误。

核心原理澄清 #

你提到的Windows系统定时器间隔不低于0.5ms的限制，仅适用于依赖定时器触发的等待场景：比如调用std::this_thread::sleep_for、为同步等待接口传入超时参数的场景，这类场景需要等待定时器中断触发才能结束等待，所以最小等待粒度受限于系统定时器分辨率。

而Semaphore的release操作是主动触发内核调度逻辑：会直接将等待该信号量的线程从阻塞队列调整为就绪队列，只要当前CPU存在空闲时间片，被唤醒的线程会立刻被调度执行，不需要等待下一次定时器中断，因此跨线程的唤醒延迟本身就是微秒级，你测出的0.017ms（即17微秒）是Windows平台用户态同步原语的正常延迟水平。

标准差偏高的原因 #

• 测试逻辑每次都会重新创建std::jthread，线程初始化、内核调度本身存在随机波动
• 没有对测试线程绑定CPU核心，两个线程可能被调度到不同物理核心，跨核心的缓存同步开销存在明显波动
• 系统后台其他进程/服务的调度抢占，如果刚好在调用release之后、子线程执行acquire返回之前发生抢占，就会出现明显更高的延迟值，这类离群值会直接拉高相对标准差。

测试优化建议 #

如果想要获得更稳定的测试结果，可以提前创建常驻的测试线程、将两个测试线程绑定到同一个物理核心的两个超线程上，同时拉高测试进程的调度优先级，能明显降低相对标准差。

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