在一个项目中遇到这样的情况（在Windows 7上），
当几个线程忙（我所有的cpu内核都忙）时，线程会收到一个信号量（从0增加到1）。 它可能长达1.5ms。
我通过caching一些东西来解决这个问题，并提前增加信号值。
所以对我来说，信号量似乎很慢，线程并不立即收到（特别是在cpu忙的时候），但是如果在某个线程开始等待之前发出信号，那么就不会有任何延迟。
劫持系统调用
真的有办法唯一地识别任何电脑
我的线程在就绪队列中吗？
OpenGL – 与未来的上下文共享现有的纹理？
在Windows上混合使用Qt和Objective-C
我曾经认为事件只是一个最大值为1的信号量，好吧，现在遇到这种情况，我开始怀疑事件是否比信号量更快地注意到线程“醒来”。
对不起，我试过了，但没有演示出来，我还不是很擅长线程。
编辑：这是事实是比Windows上的信号量更快？
Linux下C ++audio捕获API的最佳实践？
.Net框架4 Windows XP应用程序
Windows上大量连续的虚拟内存分配
UNICODE，UTF-8和Windows混乱
1.5毫秒不是由不同的多线程原语之间的开销解释的。
为了简化，线程有三个状态
受阻
可运行
赛跑
如果一个线程正在等待一个信号量或一个事件，那么它就被阻塞了。 当事件发信号时，它变成可运行的。
所以真正的问题是，“一个可运行的线程何时运行？ 这根据调度算法等而有所不同，但显然它需要在核心上运行，这意味着没有其他任何东西可以同时在核心上“运行”。 当下列情况发生时，调度程序通常会将当前正在运行的线程从“核心”中“移除”
它等待一个信号量/事件，并因此变成“阻塞”
它一直在运行一段时间（基于时间的或循环调度）
更高优先级的线程变成可运行的。
1.5毫秒可能是循环，或基于时间的调度。 你的线程是可运行的，但还没有开始。 如果线程必须启动，并且应该引导当前线程，那么你可以尝试通过SetThreadPriority来提高它的优先级
http://msdn.microsoft.com/en-us/library/windows/desktop/ms686277(v=vs.85).aspx
如果一个线程正在等待一个信号量，并且它得到信号，那么这个线程将在我有限的测试中，在一个不超载的盒子上运行〜10us。
如果发生以下情况，信令和后续调度到核心的时间将会延长：
信号线程在另一个进程中，而不是任何线程被抢占。
运行信号线程需要在另一个核心上运行的线程被抢占。
该框已经被优先级更高的线程超载。
1.5ms必须代表你的盒子非常忙碌的极端情况。
在这种情况下，用事件替换信号量不会导致整体信令等待时间的显着改善，因为线程间信令所需的大部分工作/延迟与调度/调度相关在任一情况下。
