易失性和多線程？

Question

在下面的代碼：

#include <pthread.h> 
#include <unistd.h> 
#include <stdio.h> 

pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER; 
int ready = 0; 

wait() 
{ 
    int i; 
    do 
    { 
     usleep(1000); 
     pthead_mutex_lock(&mutex); 
     i = ready; 
     pthread_mutex_unlock(&mutex); 
    } while (i == 0); 
    printf("Finished\n"); 
} 

signal() 
{ 
    pthead_mutex_lock(&mutex); 
    ready = 1; 
    pthread_mutex_unlock(&mutex); 
} 

我們產卵兩個線程，我們調用wait在一個線程，然後調用另一個信號我們也讓編譯器優化積極。

現在代碼的行爲會如預期的那樣，還是我們需要做好準備工作以使其發揮作用？不同的編譯器和庫會以不同的方式處理它們嗎

編輯：我希望可能有圍繞互斥體函數，會阻止優化本身或編譯器通常不優化輪迴函數調用。

注意：我還沒有編譯和測試代碼，當我有機會時會這樣做。

Answer 1

從內核君王一些觀點：

http://kernel.org/doc/Documentation/volatile-considered-harmful.txt

Answer 2

是的，這裏總是需要volatile int ready = 0;。

更新
如果你想周圍的一些代碼片斷沒有優化，您可以使用#pragma指令周圍的代碼（如果你的編譯器支持它們）或 - 這是完全便攜 - 移動代碼分離文件和編譯這些文件沒有或幾乎沒有優化。
後一種方法可能仍然需要使用volatile關鍵字，因爲ready變量可能會被其他您可能想要優化的模塊使用。

Answer 3

如果編譯器在存在庫函數調用時假定有關全局變量的任何內容，我會感到驚訝。這就是說，波動不會讓你付出任何代價，並且它顯示你的意圖。我會把它放在那裏。

Answer 4

存在優化時需要揮發性。否則，就緒的讀取可以合法移出while循環。

假設現在對標準沒有承諾的優化限制現在可能沒什麼問題，但是隨着編譯器的改進，將會給未來的維護者帶來巨大的悲痛。

Answer 5

現在代碼將按預期工作，或者我們需要做好準備工作以使其正常工作嗎？

我會建議在這種情況下使用volatile。雖然在這種情況下似乎並不需要。

IOW，我個人會添加volatile並刪除鎖定：它不需要設置/讀取變量的值。

不同的編譯器和庫會以不同的方式處理這個問題嗎？ 我希望可能會有一些圍繞互斥函數的事情，它們會阻止圍繞自身進行優化，或者編譯器通常不會優化循環函數調用。

在你的情況下，調用函數（pthread_mutex_lock（）的）具有副作用和改變執行環境。因此，編譯器必須重新讀取全局變量，該變量可能會因調用該函數而發生變化。

要確定的是，您想諮詢C99的5.1.2.3 Program execution從哪裏借用了術語。爲了讓你的味道：

[...]訪問一個volatile對象，修改對象，修改一個文件，或調用任何做這些操作都是副作用，這是變化的函數處於執行環境的狀態。評估表達可能會產生副作用。在執行順序中的某些特定點上，稱爲順序點，先前評估的所有副作用都應完整，且不會發生後續評估的副作用。 （附錄C中給出了序列點的摘要。）

在抽象機器中，所有表達式都按照語義指定進行評估。一個實際的實現不需要評估表達式的一部分，如果它可以推斷出它的值沒有被使用並且沒有產生任何需要的副作用（包括由調用一個函數或訪問一個volatile對象引起的任何副作用）。 [...]從附錄C

摘錄：

以下是5.1.2.3中描述的序列點：
- 給一個函數調用，該參數已經被評估之後（6.5.2.2）。

並從那裏。

根據我的經驗，編譯器現在足夠聰明，甚至在積極優化時也不會對全局變量的循環控制變量做任何事情。

Answer 6

揮發性既不需要也不足夠。所以沒有理由使用它。這是不夠的，因爲沒有標準指定它將提供線程之間的可見性。這是沒有必要的，因爲pthreads標準說互斥量就足夠了。

更糟糕的是，使用它表明你是一個無能的程序員，他試圖在你的代碼上撒上魔法灰塵來讓它工作。它充滿了對貨物崇拜的編程，任何查看代碼的人都會推斷你不知道它不是必需的。更糟糕的是，他們可能認爲你覺得已經足夠了，並且他們會懷疑你寫的任何其他代碼，擔心你使用「volatile」隱藏多線程錯誤而不是修復它們。