關注、星標公眾號，直達精彩內容
來源：https://liam.page/2018/01/18/volatile-in-C-and-Cpp/
最近在討論多線程編程中的一個可能的 false sharing 問題時，有人提出加 volatile 可能可以解決問題。這種錯誤的認識荼毒多年，促使我寫下這篇文章。
Volatile 這個話題，涉及到計算機科學多個領域多個層次的諸多細節。僅靠一篇博客，很難窮盡這些細節。因此，若不對討論范圍做一些約定，很容易就有諸多漏洞。到時誤人子弟，就不好了。以下是一些基本的約定：
1. 這篇博文討論的 volatile 關鍵字，是 C 和 C++ 語言中的關鍵字。Java 等語言中，也有 volatile 關鍵字。但它們和 C/C++ 里的 volatile 不完全相同，不在這篇博文的討論范圍內。
2. 這篇博文討論的 volatile 關鍵字，是限定在 C/C++ 標準之下的。這也就是說，我們討論的內容應該是與平臺無關的，同時也是與編譯器擴展無關的。
3. 相應的，這篇文章討論的「標準」指的是 C/C++ 的標準，而不是其他什么東西。
4. 我們希望編寫的代碼是 (1) 符合標準的，(2) 性能良好的，(3) 可移植的。這里 (1) 保證了代碼執行結果的正確性，(2) 保證了高效性，(3) 體現了平臺無關性（以及編譯器擴展等的無關性）。
在談及 C/C++ 中的 volatile 關鍵字時，總有人會拿 volatile 這個英文單詞的中文解釋說事。他們把 volatile 翻譯作「易變的」。但事實上，對于翻譯來說，很多時候目標語言很難找到一個詞能夠反映源語言中單詞的全部含義和細節。此處「易變的」就無法做到這一點。
Volatile 的意思，若要詳細理解，還是應該查閱權威的英英字典。在柯林斯高階學習詞典中，volatile 是這樣解釋的：
A situation that is volatile is likely to change suddenly and unexpectedly.
這里對 volatile 的解釋有三個精髓的形容詞和副詞，體現了 volatile 的含義。
1. likely：可能的。這意味著被 volatile 形容的對象「有可能也有可能不」發生改變，因此我們不能對這樣的對象的狀態做出任何假設。
2. suddenly：突然地。這意味著被 volatile 形容的對象可能發生瞬時改變。
3. unexpectedly：不可預期地。這與 likely 相互呼應，意味著被 volatile 形容的對象可能以各種不可預期的方式和時間發生更改。
因此，volatile 其實就是告訴我們，被它修飾的對象出現任何情況都不要奇怪，我們不能對它們做任何假設。
對于程序員來說，程序本身的任何行為都必須是可預期的。那么，在程序當中，什么才叫 volatile 呢？這個問題的答案也很簡單：程序可能受到程序之外的因素影響。
考慮以下 C/C++ 代碼。
volatile int *p = /* ... */;int a, b;a = *p;b = *p;
若忽略 volatile，那么 p 就只是一個「指向 int 類型的指針」。這樣一來，a = *p; 和 b = *p; 兩句，就只需要從內存中讀取一次就夠了。因為從內存中讀取一次之后，CPU 的寄存器中就已經有了這個值；把這個值直接復用就可以了。這樣一來，編譯器就會做優化，把兩次訪存的操作優化成一次。這樣做是基于一個假設：我們在代碼里沒有改變 p 指向內存地址的值，那么這個值就一定不會發生改變。
此處說的「讀取內存」，包括了讀取 CPU 緩存和讀取計算機主存。
然而，由于 MMIP（Memory mapped I/O）的存在，這個假設不一定是真的。例如說，假設 p 指向的內存是一個硬件設備。這樣一來，從 p 指向的內存讀取數據可能伴隨著可觀測的副作用：硬件狀態的修改。此時，代碼的原意可能是將硬件設備返回的連續兩個 int 分別保存在 a 和 b 當中。這種情況下，編譯器的優化就會導致程序行為不符合預期了。
總結來說，被 volatile 修飾的變量，在對其進行讀寫操作時，會引發一些可觀測的副作用。而這些可觀測的副作用，是由程序之外的因素決定的。
CPP reference 網站是對 C 和 C++ 語言標準的整理。因此，絕大多數時候，我們可以通過這個網站對語言標準進行查詢。關于 volatile 關鍵字，有 C 語言標準和 C++ 語言標準可查。這里摘錄兩份標準對 volatile 訪問的描述。
C 語言：Every access (both read and write) made through an lvalue expression of volatile-qualified type is considered an observable side effect for the purpose of optimization and is evaluated strictly according to the rules of the abstract machine (that is, all writes are completed at some time before the next sequence point). This means that within a single thread of execution, a volatile access cannot be optimized out or reordered relative to another visible side effect that is separated by a sequence point from the volatile access.
C++ 語言：Every access (read or write operation, member function call, etc.) made through a glvalue expression of volatile-qualified type is treated as a visible side-effect for the purposes of optimization (that is, within a single thread of execution, volatile accesses cannot be optimized out or reordered with another visible side effect that is sequenced-before or sequenced-after the volatile access. This makes volatile objects suitable for communication with a signal handler, but not with another thread of execution, see std::memory_order). Any attempt to refer to a volatile object through a non-volatile glvalue (e.g. through a reference or pointer to non-volatile type) results in undefined behavior.
這里首先解釋兩組概念：值類型和序列點（執行序列）。
值類型指的是左值（lvalue）右值（rvalue）這些概念。關于左值和右值，前作有過介紹。簡單的理解，左值可以出現在賦值等號的左邊，使用時取的是作為對象的身份；右值不可以出現在賦值等號的左邊，使用時取的是對象的值。除了 lvalue 和 rvalue，C++ 還定義了其他的值類型。其中，xvalue 大體可以理解為返回右值引用的函數調用或表達式，而 glvalue 則是 lvalue 和 xvalue 之和。
序列點則是 C/C++ 中討論執行順序時會提到的概念。對于 C/C++ 的表達式來說，執行表達式有兩種類型的動作：(1) 計算某個值、(2) 副作用（例如訪問 volatile 對象，原子同步，修改文件等）。因此，如果在兩個表達式 E1 和 E2 中間有一個序列點，或者在 C++ 中 E1 于序列中在 E2 之前，則 E1 的求值動作和副作用都會在 E2 的求值動作和副作用之前。關于序列點和序列順序規則，可以參考：這里和這里。
因此我們講，在 C/C++ 中，對 volatile 對象的訪問，有編譯器優化上的副作用：
1. 不允許被優化消失（optimized out）；
2. 于序列上在另一個對 volatile 對象的訪問之前。
這里提及的「不允許被優化」表示對 volatile 變量的訪問，編譯器不能做任何假設和推理，都必須按部就班地與「內存」進行交互。因此，上述例中「復用寄存器中的值」就是不允許的。
需要注意的是，無論是 C 還是 C++ 的標準，對于 volatile 訪問的序列性，都有單線程執行的前提。其中 C++ 標準特別提及，這個順序性在多線程環境里不一定成立。
volatile 可以解決多線程中的某些問題，這一錯誤認識荼毒多年。例如，在知乎「volatile」話題下的介紹就是「多線程開發中保持可見性的關鍵字」。為了撥亂反正，這里先給出結論（注意這些結論都基于本文第一節提出的約定之上）：
1. volatile 不能解決多線程中的問題。
2. 按照 Hans Boehm & Nick Maclaren 的總結，volatile 只在三種場合下是合適的。
2.1 和信號處理（signal handler）相關的場合；
2.2 和內存映射硬件（memory mapped hardware）相關的場合；
2.3 和非本地跳轉（setjmp 和 longjmp）相關的場合。
以下我們嘗試來用 volatile 關鍵字解決多線程同步的一個基本問題：happens-before。
首先我們考慮這樣一段（偽）代碼。
// global shared databool flag = false;thread1() {flag = false;Type* value = new Type(/* parameters */);thread2(value);while (true) {if (flag == true) {apply(value);break;}}thread2.join();if (nullptr != value) { delete value; }return;}thread2(Type* value) {// do some evaluationsvalue->update(/* parameters */);flag = true;return;}
這段代碼將 thread1 作為主線程，等待 thread2 準備好 value。因此，thread2 在更新 value 之后將 flag 置為真，而 thread1 死循環地檢測 flag。簡單來說，這段代碼的意圖希望實現 thread2 在 thread1 使用 value 之前執行完畢這樣的語義。
對多線程編程稍有了解的人應該知道，這段代碼是有問題的。問題主要出在兩個方面。其一，在 thread1 中，flag = false 賦值之后，在 while 死循環里，沒有任何機會修改 flag 的值，因此在運行之前，編譯器優化可能會將 if (flag == true) 的內容全部優化掉。其二，在 thread2 中，盡管邏輯上 update 需要發生在 flag = true 之前，但編譯器和 CPU 并不知道；因此編譯器優化和 CPU 亂序執行可能會使 flag = true 發生在 update 完成之前，因此 thread1 執行 apply(value) 時可能 value 還未準備好。
在錯誤的理解中，此時就到了 volatile 登場的時候了。
首先我們考慮這樣一段（偽）代碼。
// global shared datavolatile bool flag = false; // 1.thread1() {flag = false;Type* value = new Type(/* parameters */);thread2(value);while (true) {if (flag == true) { // 2.apply(value);break;}}thread2.join();if (nullptr != value) { delete value; }return;}thread2(Type* value) {// do some evaluationsvalue->update(/* parameters */);flag = true;return;}
這里，在 (1) 處，我們將 flag 聲明為 volatile-qualified。因此，在 (2) 處，由于 flag == true 是對 volatile 變量的訪問，故而 if-block 不會被優化消失。然而，盡管 flag 是 volatile-qualified，但 value 并不是。因此，編譯器仍有可能在優化時將 thread2 中的 update 和對 flag 的賦值交換順序。此外，由于 volatile 禁止了編譯器對 flag 的優化，這樣使用 volatile 不僅無法達成目的，反而會導致性能下降。
在錯誤的理解中，可能會對 value 也加以 volatile 關鍵字修飾；頗有些「沒有什么是一個 volatile 解決不了的；如果不行，那就兩個」的意思。
// global shared datavolatile bool flag = false;thread1() {flag = false;volatile Type* value = new Type(/* parameters */); // 1.thread2(value);while (true) {if (flag == true) {apply(value);break;}}thread2.join();if (nullptr != value) { delete value; }return;}thread2(volatile Type* value) {// do some evaluationsvalue->update(/* parameters */); // 2.flag = true;return;}
在上一節代碼的基礎上，(1) 將 value 聲明為 volatile-qualified。因此 (2) 處對兩個 volatile-qualified 變量進行訪問時，編譯器不會交換他們的順序。看起來就萬事大吉了。
然而，volatile 只作用在編譯器上，但我們的代碼最終是要運行在 CPU 上的。盡管編譯器不會將 (2) 處換序，但 CPU 的亂序執行（out-of-order execution）已是幾十年的老技術了；在 CPU 執行時，value 和 flag 的賦值仍有可能是被換序了的（store-store）。
也許有人會說，x86 和 AMD64 架構的 CPU（大多數個人機器和服務器使用這兩種架構的 CPU）只允許 sotre-load 亂序，而不會發生 store-store 亂序；或者在諸如 IA64 架構的處理器上，對 volatile-qualified 變量的訪問采用了專門的指令。因而，在這些條件下，這段代碼是安全的。盡管如此，使用 volatile 會禁止編譯器優化相關變量，從而降低性能，所以也不建議依賴 volatile 在這種情況下做線程同步。另一方面，這嚴重依賴具體的硬件規范，超出了本文的約定討論范圍。
回顧一下，我們最初遇到的問題其實需要解決兩件事情。一是 flag 相關的代碼塊不能被輕易優化消失，二是要保證線程同步的 happens-before 語義。但本質上，設計使用 flag 本身也就是為了構建 happens-before 語義。這也就是說，兩個問題，后者才是核心；如有其他不用 flag 的辦法解決問題，那么 flag 就不重要。
對于當前問題，最簡單的辦法是使用原子操作。
// global shared datastd::atomic<bool> flag = false; // #include <atomic>thread1() {flag = false;Type* value = new Type(/* parameters */);thread2(value);while (true) {if (flag == true) {apply(value);break;}}thread2.join();if (nullptr != value) { delete value; }return;}thread2(Type* value) {// do some evaluationsvalue->update(/* parameters */);flag = true;return;}
由于對 std::atomic<bool> 的操作是原子的，同時構建了良好的內存屏障，因此整個代碼的行為在標準下是良定義的。
除此之外，還可以結合使用互斥量和條件變量。
// global shared datastd::mutex m; // #include <mutex>std::condition_variable cv; // #include <condition_variable>bool flag = false;thread1() {flag = false;Type* value = new Type(/* parameters */);thread2(value);std::unique_lock<std::mutex> lk(m);cv.wait(lk, [](){ return flag; });apply(value);lk.unlock();thread2.join();if (nullptr != value) { delete value; }return;}thread2(Type* value) {std::lock_guard<std::mutex> lk(m);// do some evaluationsvalue->update(/* parameters */);flag = true;cv.notify_one();return;}
這樣一來，由線程之間的同步由互斥量和條件變量來保證，同時也避免了 while (true) 死循環空耗 CPU 的情況。
來源整理于網絡素材，版權歸原作者所有，如有侵權，請聯系刪除，謝謝。
???????????????? END ???????????????? 關注我的微信公眾號，回復“加群”按規則加入技術交流群。
點擊“閱讀原文”查看更多分享，歡迎點分享、收藏、點贊、在看。
