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

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

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

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

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

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

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

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

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

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

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

總結(jié)

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