原文鏈接：http://www.cnblogs.com/swneng/p/10081210.html

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()來等待所有消費者吃完再進行生產。

轉載于:https://www.cnblogs.com/swneng/p/10081210.html

總結

以上是生活随笔為你收集整理的c#多线程同步之EventWaitHandle使用的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。