談談C++的volatile關鍵字以及常見的誤解

轉載請保留如下聲明
　　做者： 趙宗晟
　　出處： http://www.javashuo.com/article/p-kirilmwf-dz.html

近期看到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變量差異不大。