預備知識：
c#執行緒同步（1）- 臨界區＆lock
，c#執行緒同步（2）- 臨界區＆monitor
，c#執行緒同步（3）- 互斥量 mutex，c#執行緒同步（4）- 通知＆eventwaithandle一家
這次終於不用說太多話了，某人看這一系列部落格的反應總是「好長……」，以至於都不願意看下去。在這一系列開篇之前，本想應該
一、兩個星期就能解決，結果每篇總要花上一星期左右。總想把涉及的所有方面都講得盡量清楚明白，希望容易被看懂。於是總是不斷陷於考慮如何串聯各處的關係、要寫個怎樣的例子、細細考量msdn的每一句話是否妥當……能做的無用的事情也就這點兒，所以還是努力地督促著自己要盡快完成。
呵呵，還是回到正題。訊號量也算是個鼎鼎大名的東西吧，提到互斥量總會說起訊號量。二者的差別很簡單，互斥量、臨界區是用於保護「乙個」需要被互斥訪問的資源，這個資源同時只有乙個執行緒能被訪問；而訊號量可以被用於管理「資源池」。在.net中semaphore類就是對windows訊號量的封裝。
跟誰更親，mutex還是eventwaithandle？
總的來說，semaphore與mutex更像是兄弟，仍然與eventwaithandle一脈不太親近：
semaphore的使用方法
所以我決定要偷懶了：
這裡，是的你會覺得已經很熟悉了，一望而知其意。其它的，請仍然記得命名字首的問題；記得名稱仍然是大小寫敏感的；最後別忘記使用semaphoresecurity類來管理命名訊號量的安全。
semaphore仍然使用waitone()請求資源，介面都來自waithandle，你已經看過很多遍了。
semaphore使用release()來表示對資源的釋放，不過與releasemutex()不同，這個函式有過載方法允許你指定釋放幾個資源。這引發了乙個問題，如果release的次數超過資源總量，那麼會引發semaphorefullexception異常。比如執行緒a和執行緒b都進入訊號量。如果執行緒b中發生了乙個程式設計錯誤，導致它呼叫release()兩次（或者release(2)），則兩次呼叫都會成功。這樣，訊號量的計數就已經達到了最大值，所以，當執行緒a最終呼叫release時將引發異常。這相當於本來資源中只有n個資源，最後卻有超過n個資源被還回來。
記得使用完以後呼叫close()釋放訊號量資源。
sample code
嘿嘿，沒有。因為我實在想不出有什麼特別適合sempore的簡單例子，總不能把mutex那個應用程式單例的例子改成允許啟動指定個數吧。等想到了，再來補上吧。就請先參見msdn上的相關示例**吧。
執行緒訊號量同步
thread sem.c include include include include define thread number 3 define repeat number 3 define delay time levels 10.0 sem t sem thread number void ...
執行緒同步 訊號量
執行緒同步方法 訊號量不常用，找到個帖子不錯，記錄一下！依賴的標頭檔案 include 函式宣告 sem t 表示訊號量 int sem init sem t sem,int pshared,unsigned int value 名稱 sem init 功能 initialize an unname...
執行緒同步 訊號量
進化版的互斥鎖 1 n 由於互斥鎖的粒度比較大，如果我們希望在多個執行緒間對某一物件的部分資料進行共享，使用互斥鎖是沒有辦法實現的，只能將整個資料物件鎖住。這樣雖然達到了多執行緒操作共享資料時保證資料正確性的目的，卻無形中導致執行緒的併發性下降。執行緒從並行執行，變成了序列執行。與直接使用單程序無異...