c#多線程同步之EventWaitHandle使用

文章原始出處 http://xxinside.blogbus.com/logs/47523285.html

預備知識：C#線程同步（1）- 臨界區＆Lock，C#線程同步（2）- 臨界區＆Monitor，C#線程同步（3）- 互斥量 Mutex

WaitHandle一家

　　在前一篇咱們已經提到過Mutex和本篇的主角們直接或間接繼承自WaitHandle：

Mutex類，這個咱們在上一篇已經講過。
EventWaitHandle 類及其派生類AutoResetEvent 和 ManualResetEvent，這是本篇的主角。
Semaphore 類，即信號量，咱們下一篇再講。
　　WaitHandle提供了若干用於同步的方法。上一篇關於Mutex的blog中已經講到一個WaitOne()，這是一個實例方法。除此以外，WaitHandle另有3個用於同步的靜態方法：

SignalAndWait(WaitHandle, WaitHandle)：以原子操做的形式，向第一個WaitHandle發出信號並等待第二個。即喚醒阻塞在第一個WaitHandle上的線程/進程，而後本身等待第二個WaitHandle，且這兩個動做是原子性的。跟WaitOne()同樣，這個方法另有兩個重載方法，分別用Int32或者TimeSpan來定義等待超時時間，以及是否從上下文的同步域中退出。
WaitAll(WaitHandle[])：這是用於等待WaitHandle數組裏的全部成員。若是一項工做，須要等待前面全部人完成才能繼續，那麼這個方法就是一個很好的選擇。仍然有兩個用於控制等待超時的重載方法，請自行參閱。
WaitAny(WaitHandle[])：與WaitAll()不一樣，WaitAny只要等到數組中一個成員收到信號就會返回。若是一項工做，你只要等最快作完的那個完成就能夠開始，那麼WaitAny()就是你所須要的。它一樣有兩個用於控制等待超時的重載。
線程相關性（Thread Affinity ）

　　EventWaitHandle和Mutex二者雖然是派生自同一父類，但有着徹底不一樣的線程相關性：

Mutex與Monitor同樣，是「線程相關（Thread Affinity）」的。咱們以前已經提到過，只有經過Monitor.Enter()/TryEnter()得到對象鎖的線程才能調用Pulse()/Wait()/Exit()；一樣的，只有得到Mutex擁有權的線程才能執行ReleaseMutex()方法，不然就會引起異常。這就是所謂的線程相關性。
相反，EventWaitHandle以及它的派生類AutoResetEvent和ManualResetEvent都是線程無關的。任何線程均可以發信號給EventWaitHandle，以喚醒阻塞在上面的線程。
下一篇要提到的Semaphore也是線程無關的。
Mutex與Event

　　咱們在Mutex一篇中沒有具體提到Mutex是否能發送信號，只是簡單說Mutex不太適合有相互消息通知的同步，它僅有的一些同步方法是來自其父類的靜態方法。那麼如今咱們能夠仔細來看看Mutex到底能不能用於關於Monitor那篇提到的生產者、消費者和糖罐的場景。

　　回過頭來仔細查看Mutex的全部方法，除了一個咱們已經提到的WaitHandle上的靜態方法SingnalAndWait(toSingnal, toWaitOn)，咱們找不到任何「屬於Mutex本身」的、用於發送信號的方法。退而求其次吧，咱們就來看看這個靜態方法是否可讓Mutex具備通知的能力。

　　若是toSignal是一個Mutex，那麼收到「信號」就等效於ReleaseMutex()。而因爲Mutex的線程相關性，只有擁有當前Mutex的線程纔可以發送這個信號（ReleaseMutex），不然會引起異常。也就是說若是要用這個方法來通知其它線程同步，Mutex只能本身發給本身。與之相反，若是第二個參數toWaitOn也是個Mutex，那麼這個Mutex不能是本身。由於前篇已經講過，Mutex的擁有者能夠屢次WaitOne()而不阻塞，這裏也是同樣。因此若是Mutex必定要使用這個方法，準確的說是隻是成爲這個方法的參數，那隻能是WaitHandle.SignalAndWait(它本身,另外一個Mutex)。

　　試想，若是有人試圖只使用Mutex來進行同步通知。假設生產者線程經過Mutex上的WaitOne()得到了mutexA的擁有權，而且在生產完畢後調用了SingnalAndWait(mutexA,mutexB)，通知因爲當前mutexA而阻塞的消費者線程，而且將本身阻塞在mutexB上。那麼被喚醒的消費者線程得到MutexA的擁有權吃掉糖後，也只能調用SingnalAndWait(mutexA,mutexB)釋放它得到的mutexA且阻塞於MutexB。問題來了，此時的生產者是阻塞在mutexB上……也許，咱們能夠設計一段「精巧」的代碼，讓生產者和消費者一下子阻塞在mutexA，一下子阻塞在mutexB上……我不想花費這個力氣去想了，你能夠試試看：）。無論有沒有這樣的可能，Mutex很明顯就不適用於通知的場景。

EventWaitHandle的獨門祕笈

　　正由於Mutex沒有很好地繼承父輩的衣鉢，EventWaitHandle以及它的兒子/女兒們便來到了這個世界上。

　　EventWaitHandle、AutoResetEvent、ManualResetEvent名字裏都有一個「Event」，不過這跟.net的自己的事件機制徹底沒有關係，它不涉及任何委託或事件處理程序。相對於咱們以前碰到的Monitor和Mutex須要線程去爭奪「鎖」而言，咱們能夠把它們理解爲一些須要線程等待的「事件」。線程經過等待這些事件的「發生」，把本身阻塞起來。一旦「事件」完成，被阻塞的線程在收到信號後就能夠繼續工做。

　　爲了配合WaitHandle上的3個靜態方法SingnalAndWait()/WailAny()/WaitAll()，EventWaitHandle提供了本身獨有的，使「Event」完成和從新開始的方法：

bool:Set()：英文版MSDN：Sets the state of the event to signaled, allowing one or more waiting threads to proceed；中文版MSDN：將事件狀態設置爲終止狀態，容許一個或多個等待線程繼續。初看「signaled」和「終止」彷佛並不對應，細想起來這二者的說法其實也不矛盾。事件若是在進行中，固然就沒有「終止」，那麼其它線程就須要等待；一旦事件完成，那麼事件就「終止」了，因而咱們發送信號喚醒等待的線程，因此「信號已發送」狀態也是合理的。兩個小細節：
不管中文仍是英文版，都提到這個方法都是可讓「一個」或「多個」等待線程「繼續/Proceed」（注意不是「喚醒」）。因此這個方法在「喚醒」這個動做上是相似於Monitor.Pulse()和Monitor.PulseAll()的。至於何時相似Pulse()，又在何時相似PulseAll()，往下看。
這個方法有bool型的返回值：若是該操做成功，則爲true；不然，爲false。不過MSDN並無告訴咱們，何時執行會失敗，你只有找個微軟MVP問問了。
bool:Reset()：Sets the state of the event to nonsignaled, causing threads to block. 將事件狀態設置爲非終止狀態，致使線程阻止。 一樣，咱們須要明白「nonsignaled」和「非終止」是一回事情。還一樣的是，仍然有個無厘頭的返回值。Reset()的做用，至關於讓事件從新開始處於「進行中」，那麼此後全部WaitOne()/WaitAll()/WaitAny()/SignalAndWait()這個事件的線程都會再次被擋在門外。
　　來看看EventWaitHandle衆多構造函數中最簡單的一個：

EventWaitHandle(Boolean initialState, EventResetMode mode)：初始化EventWaitHandle類的新實例，並指定等待句柄最初是否處於終止狀態，以及它是自動重置仍是手動重置。大多數時候咱們會在第一個參數裏使用false，這樣新實例會缺省爲「非終止」狀態。第二個參數EventResetMode是一個枚舉，一共兩個值：
EventResetMode.AutoReset：當Set()被調用當前EventWaitHandle轉入終止狀態時，如有線程阻塞在當前EventWaitHandle上，那麼在釋放一個線程後EventWaitHandle就會自動重置（至關於自動調用Reset()）再次轉入非終止狀態，剩餘的原來阻塞的線程（若是有的話）還會繼續阻塞。若是調用Set()後本沒有線程阻塞，那麼EventWaitHandle將保持「終止」狀態直到一個線程嘗試等待該事件，這個該線程不會被阻塞，此後EventWaitHandle纔會自動重置並阻塞那以後的全部線程。 　　
EventResetMode.ManualReset：當終止時，EventWaitHandle 釋放全部等待的線程，並在手動重置前，即Reset()被調用前，一直保持終止狀態。
　　好了，如今咱們能夠清楚的知道Set()在何時分別相似於Monitor.Pulse()/PulseAll()了：

當EventWaitHandle工做在AutoReset模式下，就喚醒功能而言，Set()與Monitor.Pulse()相似。此時，Set()只能喚醒衆多（若是有多個的話）被阻塞線程中的一個。但二者仍有些差異：
Set()的做用不只僅是「喚醒」而是「釋放」，可讓線程繼續工做（proceed）；相反，Pulse()喚醒的線程只是從新進入Running狀態，參與對象鎖的爭奪，誰都不能保證它必定會得到對象鎖。
Pulse()的已被調用的狀態不會被維護。所以，若是在沒有等待線程時調用Pulse()，那麼下一個調用Monitor.Wait()的線程仍然會被阻塞，就像Pulse() 沒有被被調用過。也就是說Monitor.Pulse()只在調用當時發揮做用，並不象Set()的做用會持續到下一個WaitXXX()。
在一個工做在ManualReset模式下的EventWaitHandle的Set()方法被調用時，它所起到的喚醒做用與Monitor.PulseAll()相似，全部被阻塞的線程都會收到信號被喚醒。而二者的差異與上面徹底相同。
　　來看看EventWaitHandle的其它構造函數：

EventWaitHandle(Boolean initialState, EventResetMode mode, String name)：頭兩個參數咱們已經看過，第三個參數name用於在系統範圍內指定同步事件的名稱。是的，正如咱們在Mutex一篇中提到的，因爲父類WaitHandle是具備跨進程域的能力的，所以跟Mutex同樣，咱們能夠建立一個全局的EventWaitHandle，讓後將它用於進程間的通知。注意，name仍然是大小寫敏感的，仍然有命名前綴的問題跟，你能夠參照這裏。當name爲null或空字符串時，這等效於建立一個局部的未命名的EventWaitHandle。仍然一樣的還有，可能會由於已經系統中已經有同名的EventWaitHandle而僅僅返回一個實例表示同名的EventWaitHandle。因此最後仍舊一樣地，若是你須要知道這個EventWaitHandle是否由你最早建立，你須要使用如下兩個構造函數之一。
EventWaitHandle(Boolean initialState, EventResetMode mode, String name, out Boolean createdNew)：createdNew用於代表是否成功建立了EventWaitHandle，true代表成功，false代表已經存在同名的事件。
EventWaitHandle(Boolean initialState, EventResetMode mode, String name, out Boolean createdNew, EventWaitHandleSecurity)：關於安全的問題，直接查看這個構造函數上的例子吧。全局MutexEventWaitHandle的安全問題應該相對Mutex更須要注意，由於有可能黑客程序用相同的事件名對你的線程發送信號或者進行組織，那樣可能會嚴重危害你的業務邏輯。
　　好啦，都差很少了，能夠寫一個例子試試了。讓咱們回到Monitor一篇中提到的生產者和消費者場景，讓咱們看看EventWaitHandle能不能完成它兄弟Mutex沒有能完成的事業。不過，即使有強大通訊能力的EventWaitHandle出馬，也避免不要使用lock/monitor或是Mutex。緣由很簡單，糖罐是一個互斥資源，必須被互斥地訪問。而EventWaitHanldle跟Mutex相反，能通訊了但卻徹底失去了臨界區的能力。因此，這個例子其實並不太適合展現EventWaitHandle的通訊機制，我只是爲了想用一樣的例子來比較這些同步機制間的差別。

　　EventWaitHandle雖然還必須藉助lock/Monitor/Mutex來實現這個例子（僅僅是臨界區部分），可是它終究有強於Monitor的通訊能力，因此讓咱們來擴展一下這個例子：如今有一個生產者，有多個消費者。

咱們讓消費者在沒有糖吃或吃完一塊糖後阻塞在一個工做在ManualReset模式下的EventWaitHandle，生產者在生產完畢後就經過這個事件喚醒全部消費者吃糖。因爲咱們使用了lock的關係，雖然全部消費者都被喚醒，可是他們仍是由於爭奪糖罐的關係只有一個能進入臨界區吃糖。不過此時阻塞的緣由並非由於咱們的通知時間，而是臨界區的問題。 每一個消費者有一條專線，即一個工做在AutoRest模式下的EventWaitHandle，用於在吃完糖後通知生產者。而生產者用WaitAny()來等待消費者吃糖時間的發生，只要有任一消費者吃完糖，那麼生產者就試圖爭奪對糖罐的擁有權，把糖罐塞滿（一人一顆的標準）。消費者這裏使用了WaitAndSignal給生產者發消息，並等待生產者進入臨界區生產糖後通知他們。在這樣的設計邏輯下，可能糖罐中的糖尚未所有吃完生產者就有機會再次把糖罐裝滿。固然，你也可使用了WaitAll()來等待全部消費者吃完再進行生產。