相较于互斥对象(Mutex)和临界区对象(Critical Section) ，信号量没有所有者，它们只有计数。
ReleaseSemaphore 函数将会以指定的数量增加对应信号量对象的计数。 (增加计数这个动作，可能会释放正在等待的线程）但是释放信号量的线程不必与最初声明它的线程相同。这与互斥对象和临界区对象不同，后者要求声明线程也是释放线程。
有些人以类似互斥对象的方式使用信号量: 他们创建一个初始计数为 1 的信号量，并像这样使用它，如下面代码所示：
WaitForSingleObject(hSemaphore, INFINITE);
… do stuff ..
ReleaseSemaphore(hSemaphore, 1, NULL);如果线程在设法释放信号量之前退出（或崩溃），则信号量计数器不会自动还原。相较于互斥对象，如果所有者线程在持有互斥对象时终止，则释放互斥对象。因此，对于这种使用模式，使用互斥对象更加合适一些。
如果资源的概念所有权可以跨线程，则信号量非常有用。我们来看下图：
此技巧不适用于互斥对象或临界区对象，因为互斥对象和临界区对象具有所有者，并且只有所有者才能释放互斥对象或临界区对象。
请注意，如果 KeepWorking 函数退出并忘记释放信号量，则计数器不会自动恢复。操作系统不知道信号量”属于”该工作项。
信号量的另一种常见用法模式与资源保护模式相反：它是资源生成模式。在此模型中，信号量计数通常为零，但在有工作要完成时递增。
请注意，在这种情况下，甚至没有信号量的概念”所有者”，除非你将工作项本身（位于工作列表数据结构上的某处）视为所有者。如果 ProcessWork 线程退出，则不希望自动释放信号量，那会破坏掉内部计数。在这种情况下，信号量是合适的对象。
(生产者/使用者信号量的更高性能版本是 I/O 完成端口。)
总结
既然提到了所谓的高性能版本，我想原作者所表达的意思是：对于尔等 C++ 工人来说，平常使用无妨，但是如果是性能攸关的代码，频繁地切换内核上下文所带来的性能开销，不可小视。
