2009-09-22 148 views

回答

64

Joe Duffy的"Concurrent Programming On Windows"提到了這個(P311-312,P598)。這一點很有趣:

注意,在上述所有例子中,線程必須是有彈性的東西叫做僞喚醒UPS - 代碼,使用它過早甦醒狀態變量應該甚至在案件保持正確的活潑也就是說,在所尋求的條件已經建立之前。這並不是因爲實現實際上會做這樣的事情(雖然在Java和Pthread等其他平臺上的某些實現已知可以這樣做),也不是因爲代碼在不需要時會故意喚醒線程,而是由於事實上沒有保證當一個被喚醒的線程將被安排。條件變量不公平。有可能 - 甚至有可能 - 另一個線程將獲得關聯的鎖並在被喚醒的線程有機會重新獲取鎖並返回關鍵區域之前使條件再次成爲假。

然後,他給出了測試條件的while循環的正常模式。

我要說的是,從這個它是合理的期望,Monitor.Wait不會通常可喚醒你過早,而且如果你絕對知道沒有別的事情可以發生變化的情況,那麼你可能能在沒有條件循環的情況下離開:但無論如何,包括它是安全的,以防萬一您的邏輯不準確。

+0

虛假喚醒的非常好的解釋。謝謝! – Gili 2009-09-22 19:03:32

+0

我正在與喬直接查看我的推斷是否正確。 – 2009-09-22 19:06:15

+0

喬對此有何迴應?在同一本書的第207頁中,他指出,CLR在您阻塞的任何時候都會使用一個常用的(可警告的)等待例程,包括阻止對Monitor的調用。這是否意味着除了你提到的「明顯的」虛假喚醒之外,你的等待還可能受到由異步程序調用引起的「真正的」超時喚醒? – 2010-02-03 07:35:52