爲什麼pthread_cond_wait有虛假喚醒？

Question

引述手冊頁：

當使用條件變量始終存在涉及與每個條件等待這是真的，如果線程應進行相關的共享變量的布爾謂詞。可能會發生來自pthread_cond_timedwait（）或pthread_cond_wait（）函數的虛假喚醒。由於從pthread_cond_timedwait（）或pthread_cond_wait（）返回並不意味着這個謂詞的值，所以在返回時應該重新評估謂詞。

因此，即使您沒有發出信號，pthread_cond_wait也會返回。乍一看，這似乎很殘酷。它會像一個函數，它在實際達到正確的返回語句之前隨機返回錯誤的值或隨機返回。這似乎是一個主要的錯誤。但他們選擇在手冊頁中記錄而不是修復它的事實似乎表明，爲什麼pthread_cond_wait最終會虛假地醒來。據推測，它是如何工作的內在原因使得它無法得到幫助。問題是什麼。

爲什麼確實pthread_cond_wait虛假地返回？爲什麼它不能保證只有當信號正確時才醒來？任何人都可以解釋其虛假行爲的原因嗎？

Answer 1

下面的解釋是由David R. Butenhof在"Programming with POSIX Threads"（第80頁）給出：

虛假喚醒可能聽起來很奇怪，但在一些多處理器系統，使得狀態喚醒完全可以預測可能會大幅放緩的所有條件可變操作。

在下面comp.programming.threads discussion，他在設計背後的思維拓展：

 
Patrick Doyle wrote: 
> In article , Tom Payne wrote: 
> >Kaz Kylheku wrote: 
> >: It is so because implementations can sometimes not avoid inserting 
> >: these spurious wakeups; it might be costly to prevent them. 

> >But why? Why is this so difficult? For example, are we talking about 
> >situations where a wait times out just as a signal arrives? 

> You know, I wonder if the designers of pthreads used logic like this: 
> users of condition variables have to check the condition on exit anyway, 
> so we will not be placing any additional burden on them if we allow 
> spurious wakeups; and since it is conceivable that allowing spurious 
> wakeups could make an implementation faster, it can only help if we 
> allow them. 

> They may not have had any particular implementation in mind. 

You're actually not far off at all, except you didn't push it far enough. 

The intent was to force correct/robust code by requiring predicate loops. This was 
driven by the provably correct academic contingent among the "core threadies" in 
the working group, though I don't think anyone really disagreed with the intent 
once they understood what it meant. 

We followed that intent with several levels of justification. The first was that 
"religiously" using a loop protects the application against its own imperfect 
coding practices. The second was that it wasn't difficult to abstractly imagine 
machines and implementation code that could exploit this requirement to improve 
the performance of average condition wait operations through optimizing the 
synchronization mechanisms. 
/------------------[ David.Buten...@compaq.com ]------------------\ 
| Compaq Computer Corporation    POSIX Thread Architect | 
|  My book: http://www.awl.com/cseng/titles/0-201-63392-2/  | 
\-----[ http://home.earthlink.net/~anneart/family/dave.html ]-----/ 

Answer 2

至少有兩件事情「虛假喚醒」可能意味着：

• 阻塞在一個線程即使沒有呼叫發送信號或廣播發生，pthread_cond_wait也可以從呼叫中返回。
• pthread_cond_wait中的一個線程因爲調用信號或廣播而返回，但重新獲取互斥體後，發現底層謂詞不再成立。

但是即使條件變量實現不允許前一種情況，後一種情況也會發生。考慮一個生產者消費者隊列和三個線程。

• 線程1剛剛出列了一個元素並釋放了互斥量，而隊列現在是空的。該線程正在處理它在某些CPU上獲取的元素。
• 線程2嘗試使元素出列，但在互斥體下檢查時發現隊列爲空，調用pthread_cond_wait，並在呼叫等待信號/廣播中阻塞。
• 線程3獲取互斥鎖，向隊列中插入新元素，通知條件變量並釋放鎖。
• 作爲對來自線程3的通知的響應，等待條件的線程2計劃運行。
• 但是，在線程2設法獲取CPU並獲取隊列鎖之前，線程1完成當前任務並返回隊列以進行更多工作。它獲得隊列鎖定，檢查謂詞，並發現隊列中有工作。它繼續出線插入線程3的項目，釋放鎖定，並執行線程3入隊的項目。
• 線程2現在獲取一個CPU並獲取鎖，但是當它檢查謂詞時，它會發現隊列爲空。線程1'偷了'這個項目，所以喚醒似乎是虛假的。線程2需要再次等待條件。

因此，既然您已經總是需要檢查循環下的謂詞，如果底層條件變量可能有其他類型的虛假喚醒，則沒有區別。

Answer 3

pthread_cond_signal中的「條件信號的多重覺醒」部分具有涉及虛假wakekups的pthread_cond_wait和pthread_cond_signal的示例實現。