近期看到C++標準中對volatile關鍵字的定義，發現和java的volatile關鍵字完全不一樣，C++的volatile對併發編程基本沒有幫助。網上也看到很多關於volatile的誤解，於是決定寫這篇文章詳細解釋一下volatile的作用到底是什麼。
編譯器對代碼的優化
在講volatile關鍵字之前，先講一下編譯器的優化。
int main() {
int i = 0;
i++;
cout << "hello world" << endl;
}
按照代碼，這個程序會在內存中預留int大小的空間，初始化這段內存爲0，然後這段內存中的數據加1，最後輸出“hello world”到標準輸出中。但是根據這段代碼編譯出來的程序（加-O2選項），不會預留int大小的內存空間，更不會對內存中的數字加1。他只會輸出“hello world”到標準輸出中。
其實不難理解，這個是編譯器爲了優化代碼，修改了程序的邏輯。實際上C++標準是允許寫出來的代碼和實際生成的程序不一致的。雖說優化代碼是件好事情，但是也不能讓編譯器任意修改程序邏輯，不然的話我們沒辦法寫可靠的程序了。所以C++對這種邏輯的改寫是有限制的，這個限制就是在編譯器修改邏輯後，程序對外界的IO依舊是不變的。怎麼理解呢？實際上我們可以把我們寫出來的程序看做是一個黑匣子，如果按照相同的順序輸入相同的輸入，他就每次都會以同樣的順序給出同樣的輸出。這裏的輸入輸出包括了標準輸入輸出、文件系統、網絡IO、甚至一些system call等等，所有程序外部的事物都包含在內。所以對於程序使用者來說，只要兩個黑匣子的輸入輸出是完全一致的，那麼這兩個黑匣子是一致的，所以編譯器可以在這個限制下任意改寫程序的邏輯。這個規則又叫as-if原則。
volatile關鍵字的作用
不知道有沒有注意到，剛剛提到輸入輸出的時候，並沒有提到內存，事實上，程序對自己內存的操作不屬於外部的輸入輸出。這也是爲什麼在上述例子中，編譯器可以去除對i變量的操作。但是這又會出現一個麻煩，有些時候操作系統會把一些硬件映射到內存上，讓程序通過對內存的操作來操作這個硬件，比如說把磁盤空間映射到內存中。那麼對這部分內存的操作實際上就屬於對程序外部的輸入輸出了。對這部分內存的操作是不能隨便修改順序的，更不能忽略。這個時候volatile就可以派上用場了。按照C++標準，對於glvalue的volatile變量進行操作，與其他輸入輸出一樣，順序和內容都是不能改變的。這個結果就像是把對volatile的操作看做程序外部的輸入輸出一樣。（glvalue是值類別的一種，簡單說就是內存上分配有空間的對象，更詳細的請看我的另一篇文章。）
按照C++標準，這是volatile唯一的功能，但是在一些編譯器（如，MSVC）中，volatile還有線程同步的功能，但這就是編譯器自己的拓展了，並不能跨平臺應用。
對volatile常見的誤解
實際上“volatile可以在線程間同步”也是比較常見的誤解。比如以下的例子：
class AObject
{
public:
void wait()
{
m_flag = false;
while (!m_flag)
{
this_thread::sleep(1000ms);
}
}
void notify()
{
m_flag = true;
}
private:
volatile bool m_flag;
};
AObject obj;
...
// Thread 1
...
obj.wait();
...
// Thread 2
...
obj.notify();
...
對volatile有誤解的人，或者對併發編程不瞭解的人可能會覺得這段邏輯沒什麼問題，可能會認爲volatile保證了，wait()對m_flag的讀取，notify()對m_flag的寫入，所以Thread 1能夠正常醒來。實際上並不是這麼簡單，因爲在多核CPU中，每個CPU都有自己的緩存。緩存中存有一部分內存中的數據，CPU要對內存讀取與存儲的時候都會先去操作緩存，而不會直接對內存進行操作。所以多個CPU“看到”的內存中的數據是不一樣的，這個叫做內存可見性問題（memory visibility）。放到例子中就是，Thread 2修改了m_flag對應的內存，但是Thread 1在其他CPU核上運行，所以Thread 1不一定能看到Thread 2對m_flag做的更改。C++11開始，C++標準中有了線程的概念，C++標準規定了什麼情況下一個線程一定可以看到另一個線程做的內存的修改。而根據標準，上述例子中的Thread 1可能永遠看不到m_flag變成true，更嚴重的是，Thread 1對m_flag的讀取會導致Undefined Behavior。
從C++標準來說，這段代碼是Undefined Behavior，既然是Undefined Behavior的話，是不是也可能正確執行？是的，熟悉MESI的應該會知道，Thread 2的修改導致緩存變髒，Thread 1讀取內存會試圖獲取最新的數據，所以這段代碼可以正常執行。那是不是就意味着我們可以放心使用volatile來做線程的同步？不是的，只是在這個例子能夠正確執行而已。我們對例子稍作修改，volatile就沒那麼好使了。
class AObject
{
public:
void wait()
{
m_flag = false;
while (!m_flag)
{
this_thread::sleep(1000ms);
}
}
void notify()
{
m_flag = true;
}
private:
volatile bool m_flag;
};
AObject obj;
bool something = false;
...
// Thread 1
...
obj.wait();
assert(something)
...
// Thread 2
...
something = true;
obj.notify();
...
在以上代碼中，Thread 1的assert語句可能會失敗。就如前文所說，C++編譯器在保證as-if原則下可以隨意打亂變量賦值的順序，甚至移除某個變量。所以上述例子中的“something = true"語句可能發生在obj.notify()之後。這樣的話，“assert(something)”就會失敗了。
那麼我們可不可能把something也變成volatile？如果something是volatile，我們確實能夠保證編譯出來的程序中的語句順序和源代碼一致，但我們仍然不能保證兩個語句是按照源代碼中的順序執行，因爲現代CPU往往都有亂序執行的功能。所謂亂序執行，CPU會在保證代碼正確執行的基礎上，調整指令的順序，加快程序的運算，更多細節我們不在這裏展開。我們如果單看Thread 2線程，something和m_flag這兩個變量的讀寫是沒有依賴關係的，而Thread 2線程看不到這兩個變量在其他線程上的依賴關係，所以CPU可能會打亂他們的執行順序，或者同時執行這兩個指令。結果就是，在Thread 1中，obj.wait()返回後，something可能仍然是false，assert失敗。當然，會不會出現這樣的狀況，實際上也和具體的CPU有關係。但是我們知道錯誤的代碼可能會引起錯誤的結果，我們應該避免錯誤的寫法，而這個錯誤就在於誤用了volatile關鍵字，volatile可以避免優化、強制內存讀取的順序，但是volatile並沒有線程同步的語義，C++標準並不能保證它在多線程情況的正確性。
那麼用不了volatile，我們該怎麼修改上面的例子？C++11開始有一個很好用的庫，那就是atomic類模板，在<atomic>頭文件中，多個線程對atomic對象進行訪問是安全的，並且提供不同種類的線程同步。不同種類的線程同步非常複雜，要涉及到C++的內存模型與併發編程，我就不在此展開。它默認使用的是最強的同步，所以我們就使用默認的就好。以下爲修改後的代碼：
class AObject
{
public:
void wait()
{
m_flag = false;
while (!m_flag)
{
this_thread::sleep(1000ms);
}
}
void notify()
{
m_flag = true;
}
private:
atomic<bool> m_flag;
};
只要把“volatile bool”替換爲“atomic<bool>”就可以。<atomic>頭文件也定義了若干常用的別名，例如“atomic<bool>”就可以替換爲“atomic_bool”。atomic模板重載了常用的運算符，所以atomic<bool>使用起來和普通的bool變量差別不大。