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

ReleaseSemaphore 函數(shù)將會(huì)以指定的數(shù)量增加對應(yīng)信號量對象的計(jì)數(shù)。 (增加計(jì)數(shù)這個(gè)動(dòng)作，可能會(huì)釋放正在等待的線程）但是釋放信號量的線程不必與最初聲明它的線程相同。這與互斥對象和臨界區(qū)對象不同，后者要求聲明線程也是釋放線程。

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

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

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

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

此技巧不適用于互斥對象或臨界區(qū)對象，因?yàn)榛コ鈱ο蠛团R界區(qū)對象具有所有者，并且只有所有者才能釋放互斥對象或臨界區(qū)對象。

請注意，如果 KeepWorking 函數(shù)退出并忘記釋放信號量，則計(jì)數(shù)器不會(huì)自動(dòng)恢復(fù)。操作系統(tǒng)不知道信號量”屬于”該工作項(xiàng)。

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

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

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

總結(jié)

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