在一个项目中我遇到了这样的案例（在Windows 7上），
当多个线程忙时（我的所有CPU内核都忙着工作），线程会有延迟 接收信号量（从0增加到1）。它可能长达1.5毫秒。
我通过缓存一些东西来解决这个问题，并提前增加信号量值。
所以对我来说，信号似乎信号很慢，它没有被线程立即接收（特别是当CPU忙时），但是如果你在一些线程开始等待它之前发出信号，那就没有延迟了
我曾经认为事件只是一个最大值为1的信号量，好吧，现在遇到这种情况，我开始怀疑事件是否比信号量更快注意线程“唤醒”。
对不起，我试过了，但没有发表演示，我还不太擅长线程化。
编辑： 在Windows上，Event比Semaphore更快吗？
答案 0 :(得分：3)
1.5毫秒不仅仅解释了不同多线程原语之间的开销。
为了简化，Threads有三种状态
如果线程正在等待信号量或事件，则它被阻止。当事件发出信号时，它将变为可运行。
所以真正的问题是，“可运行的线程何时实际运行？”这根据调度程序算法等而有所不同，但显然它需要在核心上运行，这意味着其他任何东西都不能同时在该核心上“运行”。当发生以下任一情况时，调度程序通常会从核心“删除”当前运行的线程
1.5毫秒可能是循环或基于时间的调度。你的线程是可以运行的，但还没有开始。如果线程必须启动，并且应该启动当前线程，那么您可以尝试通过SetThreadPriority
http://msdn.microsoft.com/en-us/library/windows/desktop/ms686277(v=vs.85).aspx
答案 1 :(得分：0)
如果一个线程正在等待一个信号量并且它被发出信号，那么该线程将在我的有限测试中，在一个没有过载的盒子上运行〜10us。
如果出现以下情况，信号传输以及随后调度到核心的时间将会更长：
发出信号的线程在另一个进程中，而不是任何线程都是preempts。
运行已发出信号的线程需要抢占在另一个核心上运行的线程。
该框已经超载了更高优先级的线程。
1.5ms必须代表您的盒子非常繁忙的极端情况。
在这种情况下，用事件替换信号量不太可能导致整体信令延迟的任何显着改善，因为线程间信令所需的大部分工作/延迟与调度/调度相关联，这两种情况都是必需的。