# 內存模型 （譯注：這一個item有相當深的理論深度，原文也比較晦澀難懂，翻譯者提醒大家，最好參照原文理解，如果翻譯中有什么不恰當的地方，還請批評指出，不勝感謝。） 所謂“內存模型”，是計算機（硬件）體系結構與編譯器雙方之間的一種約定。有了它，大多數程序員便不用處處考慮日新月異的計算機硬件細節。如果沒有內存模型，那么線程機制、鎖機制及無鎖編程等都無從談起。 內存模型的最關鍵保證是：兩個線程可以各自獨立地存取各自的“內存位置”而不會互相影響。那么，什么是“內存位置”呢？ 一個內存位置要么是一個標量類型的對象，要么是一個連續且位寬非零的最長比特域組。例如：此處的S具有四個獨立的內存位置： ``` struct S {<br /> char a; // 位置#1 int b:5, // 位置#2 int c:11, // 注意：":0"是一個“特殊符號” //（譯注：此處的":0"會將一個int對象分割為兩個內存位置， // 因為上面所講的內存位置的第二種情況需要“連續且位寬非零”） int :0, int d :8; // 位置#3 struct {int ee:8; } e; // 位置#4 }; ``` 內存模型為什么如此重要？為什么它不是顯而易見的？(譯注：此處指“為什么應用程序所使用的內存模型與計算機的物理內存結構不是直接一致的，即不用經過任何中間層”，在本例中，應當指為什么b和c屬于同一個內存位置)。 難道并非一直如此嗎？ 問題在于，如果多個計算任務真正地并發運行，那么當這些來自不同計算任務中不相關（很明顯）的指令代碼在同一時刻執行時，內存硬件的詭異行為將會被暴露無遺（譯注：一個詭異行為就是，在上述例子中，對變量b,c,d的存取，并非一次僅操作5,11或者8個bit。具體操作與處理器的行為有關）。事實上，如果沒有了編譯器的支持，指令流/數據流以及緩存命中等細節問題將會被直接暴露給應用程序開發人員，而他們對此毫無對策。即使兩個線程之間不存在數據共享，情況依然糟糕如此！考慮如下兩個分開編譯的“線程”： ``` //線程 1: char c; c = 1; int x = c; //線程 2 char b; b = 1; int y = b; ``` 為了盡量模擬現實狀態，我使用了分開編譯（對每個線程）來保證編譯器/優化器不會對內存進行優化（譯注：此處指對每個線程內的代碼進行逐行編譯，然后連接，以避免代碼優化），以防止“聰明”的編譯器跳過讀取變量c和b而直接將x和y初始化為1。那么現在，x和y的值可能是什么呢？按照C++11的標準，唯一正確的答案，也是顯而易見的那個，x和y均為1。但如果你采用了一個傳統意義上的優秀的帶預并發處理(pre-concurrency)的C或者C++編譯器，那么事情變得有趣起來：x和y的可能值會是0和0(很少發生)，或者1和0，或者0 和1，或者1和1。這些都是在“真實環境”下觀察到的情況。為何如此呢？原因在于，鏈接器可能會將變量c和b的位置分配在相鄰的內存上（在同一個word內），而且90年代的C/C++標準并未對此作出禁令（譯注：指不拒絕這種變量在內存中的存儲位置安排方式）。在這種情況下，C++就如同所有那些未考慮實際硬件并發就進行設計的語言一樣，由于現代CPU無法讀寫單個的字節，讀寫操作在處理中總是以word為單位進行的，所以，對變量c的賦值實際上是“讀取包含變量c的一個word，替換掉其中的c部分，然后再寫回這個word”。由于對變量b的賦值也是如此進行的，這就造成了兩個操作變量b和變量c的線程有如此多地機會互相干涉、影響（譯注：線程1操作變量c時，回寫操作會改變變量b的值，線程2也是如此，這就造成了兩個線程之間的干擾，而b和c也處于不穩定狀態），即使它們之間并未共享數據（由它們的源代碼來看，的確如此）。 因此，C++11保證了在“獨立的內存位置”上，肯定不會發生如上這種問題。或者換種說法：“對于同一內存位置，多個線程同時訪問時需要加鎖，除非所有的訪問都是只讀”。需要留意的是，一個單word內的不同比特域并非屬于獨立的內存位置（譯注：即它們總是被一起讀取和寫入的），所以不要輕易在線程之間共享帶有比特域的結構，除非使用鎖機制來消除潛在風險。除過這個需要特別注意的地方外，C++的內存模型就如同“大家所期待的那樣”，簡單而且純潔) （譯注：指對象結構的內存模型就按照結構中的聲明順序進行排列，而且不會發生干擾問題）。 但是，對于底層的并行計算問題，要想直接地進行考慮，并不總是那么簡單。考慮下面的代碼： ``` // 開始的時候， x==0 ，y==0 if (x) y = 1; // 線程 1 if (y) x = 1; // 線程 2 ``` 這里有沒有問題呢？或者更直接地說，這里會不會發生資源競爭呢？（答案是：不會發生） （譯注：此處范例的詳細解釋請翻閱參考資料之“Hans-J. Boehm:Threads basics”） 幸運的是，我們趕上了好時代，每一個現代C++編譯器（我所知道的）都給予上面問題正確的答案，而且它們這些年來也是如此做的。畢竟，長期以來C++一直擔任著開發并發系統中關鍵部分的重任，相應的語言標準總不能停滯不前吧。 參考： * Standard: 1.7 The C++ memory model [intro.memory] * Paul E. McKenney, Hans-J. Boehm, and Lawrence Crowl: [C++ Data-Dependency Ordering: Atomics and Memory Model](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2556.html). N2556==08-0066. * Hans-J. Boehm: [Threads basics](http://www.hpl.hp.com/techreports/2009/HPL-2009-259html.html), HPL technical report 2009-259. “what every programmer should know about memory model issues.” * Hans-J. Boehm and Paul McKenney: [A slightly dated FAQ on C++ memory model issues](http://www.hpl.hp.com/personal/Hans_Boehm/c++mm/user-faq.html).