相較于互斥對象(Mutex)和臨界區對象(Critical Section) ，信號量沒有所有者，它們只有計數。

ReleaseSemaphore 函數將會以指定的數量增加對應信號量對象的計數。 (增加計數這個動作，可能會釋放正在等待的線程）但是釋放信號量的線程不必與最初聲明它的線程相同。這與互斥對象和臨界區對象不同，后者要求聲明線程也是釋放線程。

有些人以類似互斥對象的方式使用信號量: 他們創建一個初始計數為 1 的信號量，并像這樣使用它，如下面代碼所示：

WaitForSingleObject(hSemaphore, INFINITE);
… do stuff ..
ReleaseSemaphore(hSemaphore, 1, NULL);

如果線程在設法釋放信號量之前退出（或崩潰），則信號量計數器不會自動還原。相較于互斥對象，如果所有者線程在持有互斥對象時終止，則釋放互斥對象。因此，對于這種使用模式，使用互斥對象更加合適一些。

如果資源的概念所有權可以跨線程，則信號量非常有用。我們來看下圖：

此技巧不適用于互斥對象或臨界區對象，因為互斥對象和臨界區對象具有所有者，并且只有所有者才能釋放互斥對象或臨界區對象。

請注意，如果 KeepWorking 函數退出并忘記釋放信號量，則計數器不會自動恢復。操作系統不知道信號量”屬于”該工作項。

信號量的另一種常見用法模式與資源保護模式相反：它是資源生成模式。在此模型中，信號量計數通常為零，但在有工作要完成時遞增。

請注意，在這種情況下，甚至沒有信號量的概念”所有者”，除非你將工作項本身（位于工作列表數據結構上的某處）視為所有者。如果 ProcessWork 線程退出，則不希望自動釋放信號量，那會破壞掉內部計數。在這種情況下，信號量是合適的對象。

(生產者/使用者信號量的更高性能版本是 I/O 完成端口。)

總結

既然提到了所謂的高性能版本，我想原作者所表達的意思是：對于爾等 C++ 工人來說，平常使用無妨，但是如果是性能攸關的代碼，頻繁地切換內核上下文所帶來的性能開銷，不可小視。