現(xiàn)代計算機體系結(jié)構(gòu)上，CPU執(zhí)行指令的速度遠遠大于CPU訪問內(nèi)存的速度，于是引入Cache機制來加速內(nèi)存訪問速度。除了Cache以外，分支預(yù)測和指令預(yù)取也在很大程度上提升了CPU的執(zhí)行速度。隨著SMP的出現(xiàn)，多線程編程模型被廣泛應(yīng)用，在多線程模型下對共享變量的訪問變成了一個復(fù)雜的問題。于是我們有必要了解一下內(nèi)存模型，這是多處理器架構(gòu)下并發(fā)編程里必須掌握的一個基礎(chǔ)概念。

1. 什么是內(nèi)存模型？

到底什么是內(nèi)存模型呢？看到有兩種不同的觀點：

◆ A：內(nèi)存模型是從來描述編程語言在支持多線程編程中對共享內(nèi)存訪問的順序。

◆ B：內(nèi)存模型的本質(zhì)是指在單線程情況下CPU指令在多大程度上發(fā)生指令重排(reorder)[1]。

實際上A，B兩種說法都是正確的，只不過是在嘗試從不同的角度去說明memory model的概念。個人認(rèn)為，內(nèi)存模型表達為“內(nèi)存順序模型”可能更加貼切一點。

一個良好的memory model定義包含3個方面：

◆ Atomic Operations

◆ Partial order of operations

◆ Visable effects of operations

這里要強調(diào)的是：我們這里所說的內(nèi)存模型和CPU的體系結(jié)構(gòu)、編譯器實現(xiàn)和編程語言規(guī)范3個層面都有關(guān)系。

首先，不同的CPU體系結(jié)構(gòu)內(nèi)存順序模型是不一樣的，但大致分為兩種：

x86_64和Sparc是強順序模型（Total Store Order），這是一種接近程序順序的順序模型。所謂Total，就是說，內(nèi)存（在寫操作上）是有一個全局的順序的（所有人看到的一樣的順序）， 就好像在內(nèi)存上的每個Store動作必須有一個排隊，一個弄完才輪到另一個，這個順序和你的程序順序直接相關(guān)。所有的行為組合只會是所有CPU內(nèi)存程序順序的交織，不會發(fā)生和程序順序不一致的地方[4]。TSO模型有利于多線程程序的編寫，對程序員更加友好，但對芯片實現(xiàn)者不友好。CPU為了TSO的承諾，會犧牲一些并發(fā)上的執(zhí)行效率。

弱內(nèi)存模型（簡稱WMO，Weak Memory Ordering），是把是否要求強制順序這個要求直接交給程序員的方法。換句話說，CPU不去保證這個順序模型（除非他們在一個CPU上就有依賴）， 程序員要主動插入內(nèi)存屏障指令來強化這個“可見性”[4]。ARMv8，PowerPC和MIPS等體系結(jié)構(gòu)都是弱內(nèi)存模型。每種弱內(nèi)存模型的體系架構(gòu)都有自己的內(nèi)存屏障指令，語義也不完全相同。弱內(nèi)存模型下，硬件實現(xiàn)起來相對簡單，處理器執(zhí)行的效率也高， 只要沒有遇到顯式的屏障指令，CPU可以對局部指令進行reorder以提高執(zhí)行效率。

對于多線程程序開發(fā)來說，對并發(fā)的數(shù)據(jù)訪問我們一般到做同步操作， 可以使用mutex，semaphore，conditional等重量級方案對共享數(shù)據(jù)進行保護。但為了實現(xiàn)更高的并發(fā)，需要使用內(nèi)存共享變量做通信（Message Passing）， 這就對程序員的要求很高了，程序員必須時時刻刻必須很清楚自己在做什么， 否則寫出來的程序的執(zhí)行行為會讓人很是迷惑！值得一提的是，并發(fā)雖好，如果能夠簡單粗暴實現(xiàn)，就不要搞太多投機取巧！要實現(xiàn)lock-free無鎖編程真的有點難。

其次，不同的編程語言對內(nèi)存模型都有自己的規(guī)范，例如：C/C++和Java等不同的編程語言都有定義內(nèi)存模型相關(guān)規(guī)范。

2011年發(fā)布的C11/C++11 ISO Standard為我們帶來了memory order的支持， 引用C++11里的一段描述：

memory order的問題就是因為指令重排引起的, 指令重排導(dǎo)致 原來的內(nèi)存可見順序發(fā)生了變化, 在單線程執(zhí)行起來的時候是沒有問題的, 但是放到 多核/多線程執(zhí)行的時候就出現(xiàn)問題了, 為了效率引入的額外復(fù)雜邏輯的的弊端就出現(xiàn)了[8]。

C++11引入memory order的意義在于我們現(xiàn)在有了一個與運行平臺無關(guān)和編譯器無關(guān)的標(biāo)準(zhǔn)庫， 讓我們可以在high level languange層面實現(xiàn)對多處理器對共享內(nèi)存的交互式控制。我們的多線程終于可以跨平臺啦！我們可以借助內(nèi)存模型寫出更好更安全的并發(fā)代碼。真棒，簡直不要太優(yōu)秀~

為了更好地描述內(nèi)存模型，有4種關(guān)系術(shù)語需要了解一下。

sequenced-before

同一個線程之內(nèi)，語句A的執(zhí)行順序在語句B前面，那么就成為A sequenced-before B。它不僅僅表示兩個操作之間的先后順序，還表示了操作結(jié)果之間的可見性關(guān)系。兩個操作A和操作B，如果有A sequenced-before B，除了表示操作A的順序在B之前，還表示了操作A的結(jié)果操作B可見。例如：語句A是sequenced-before語句B的。

happens-before

happens-before關(guān)系表示的不同線程之間的操作先后順序。如果A happens-before B，則A的內(nèi)存狀態(tài)將在B操作執(zhí)行之前就可見。happends-before關(guān)系滿足傳遞性、非自反性和非對稱性。happens before包含了inter-thread happens before和synchronizes-with兩種關(guān)系。

synchronizes-with

synchronizes-with關(guān)系強調(diào)的是變量被修改之后的傳播關(guān)系（propagate）， 即如果一個線程修改某變量的之后的結(jié)果能被其它線程可見，那么就是滿足synchronizes-with關(guān)系的[9]。另外synchronizes-with可以被認(rèn)為是跨線程間的happends-before關(guān)系。顯然，滿足synchronizes-with關(guān)系的操作一定滿足happens-before關(guān)系了。

Carries dependency

同一個線程內(nèi)，表達式A sequenced-before 表達式B，并且表達式B的值是受表達式A的影響的一種關(guān)系， 稱之為"Carries dependency"。這個很好理解，例如：

了解了上面一些基本概念，下面我們來一起學(xué)習(xí)一下內(nèi)存模型吧。

2. C11/C++11內(nèi)存模型

C/C++11標(biāo)準(zhǔn)中提供了6種memory order，來描述內(nèi)存模型[6]:

每種memory order的規(guī)則可以簡要描述為：

下面我們來舉例一一說明，扒開內(nèi)存模型的神秘面紗。

2.1 memory order releaxed

relaxed表示一種最為寬松的內(nèi)存操作約定，Relaxed ordering 僅僅保證load()和store()是原子操作， 除此之外，不提供任何跨線程的同步[5]。

上面的多線程模型執(zhí)行的時候，可能出現(xiàn)r2 == r1 == 42。要理解這一點并不難，因為CPU在執(zhí)行的時候允許局部指令重排reorder，D可能在C前執(zhí)行。如果程序的執(zhí)行順序是 D -> A -> B -> C，那么就會出現(xiàn)r1 == r2 == 42。

如果某個操作只要求是原子操作，除此之外，不需要其它同步的保障，那么就可以使用 relaxed ordering。程序計數(shù)器是一種典型的應(yīng)用場景：

cnt是共享的全局變量，多個線程并發(fā)地對cnt執(zhí)行RMW（Read Modify Write）原子操作。這里只保證cnt的原子性，其他有依賴cnt的地方不保證任何的同步。

2.2 memory order consume

consume要搭配release一起使用。很多時候，線程間只想針對有依賴關(guān)系的操作進行同步， 除此之外線程中其他操作順序如何不關(guān)心，這時候就適合用consume來完成這個操作。例如：

b = *a;
c = *b

第二行的變量c依賴于第一行的執(zhí)行結(jié)果，因此這兩行代碼是"Carries dependency"關(guān)系。顯然，由于consume是針對有明確依賴關(guān)系的語句來限定其執(zhí)行順序的一種內(nèi)存順序， 而releaxed不提供任何順序保證， 所以consume order要比releaxed order要更加地Strong。

assert(*p2 == "Hello")永遠不會失敗，但assert(data == 42)可能會。原因是：

• p2和ptr直接有依賴關(guān)系，但data和ptr沒有直接依賴關(guān)系，

• 盡管線程1中data賦值在ptr.store()之前，線程2看到的data的值還是不確定的。

2.3 memory order acquire

acquire和release也必須放到一起使用。 release和acquire構(gòu)成了synchronize-with關(guān)系，也就是同步關(guān)系。在這個關(guān)系下：線程A中所有發(fā)生在release x之前的值的寫操作， 對線程B的acquire x之后的任何操作都可見。

上面的例子中：

• sender線程中data = 42是sequence before原子變量ready的

• sender和receiver在C和D處發(fā)生了同步

• 線程sender中C之前的所有讀寫對線程receiver都是可見的 顯然， release和acquire組合在一起比release和consume組合更加Strong！

2.4 memory order release

release order一般不單獨使用，它和acquire和consume組成2種獨立的內(nèi)存順序搭配。

這里就不用展開啰里啰嗦了。

2.5 memory order acq_rel

acq_rel是acquire和release的疊加。

大致意思是：memory_order_acq_rel適用于read-modify-write operation， 對于采用此內(nèi)存序的read-modify-write operation，我們可以稱為acq_rel operation， 既屬于acquire operation 也是release operation. 設(shè)有一個原子變量M上的acq_rel operation：自然的，該acq_rel operation之前的內(nèi)存讀寫都不能重排到該acq_rel operation之后， 該acq_rel operation之后的內(nèi)存讀寫都不能重排到該acq_rel operation之前. 其他線程中所有對M的release operation及其之前的寫入都對當(dāng)前線程從該acq_rel operation開始的操作可見， 并且截止到該acq_rel operation的所有內(nèi)存寫入都對另外線程對M的acquire operation以及之后的內(nèi)存操作可見[13]。

2.6 memory order seq_cst

seq_cst表示順序一致性內(nèi)存模型，在這個模型約束下不僅同一個線程內(nèi)的執(zhí)行結(jié)果是和程序順序一致的， 每個線程間互相看到的執(zhí)行結(jié)果和程序順序也保持順序一致。顯然，seq_cst的約束是最強的，這意味著要犧牲性能為代價。

2.7 Relationship with volatile

人的一生總是充滿了疑惑。

可能你會思考？volatile關(guān)鍵字能夠防止指令被編譯器優(yōu)化，那它能提供線程間(inter-thread)同步語義嗎？答案是：不能！??！

• 盡管volatile能夠防止單個線程內(nèi)對volatile變量進行reorder，但多個線程同時訪問同一個volatile變量，線程間是完全不提供同步保證。

• 而且，volatile不提供原子性！

• 并發(fā)的讀寫volatile變量是會產(chǎn)生數(shù)據(jù)競爭的，同時non volatile操作可以在volatile操作附近自由地reorder。

看一個例子，執(zhí)行下面的并發(fā)程序，不出意外的話，你不會得到一個為0的結(jié)果。

3. Reference

1. The C/C++ Memory Model: Overview and Formalization

2. 知乎專欄：如何理解C++的6種memory order

3. 理解 C++ 的 Memory Order

4. 理解弱內(nèi)存順序模型

5. 當(dāng)我們在談?wù)?memory order 的時候，我們在談?wù)撌裁?

6. https://en.cppreference.com/w/cpp/atomic/memory_order

7. Youtube: Atomic’s memory orders, what for? - Frank Birbacher [ACCU 2017]

8. C++11中的內(nèi)存模型下篇 - C++11支持的幾種內(nèi)存模型

9. memory ordering, Gavin's blog

10. c++11 內(nèi)存模型解讀

11. memory barriers in c, MariaDB FOUNDATION, pdf

12. C++ memory order循序漸進

13. Memory Models for C/C++ Programers

14. Memory Consistency Models: A Tutorial

(END)

免責(zé)聲明：本文內(nèi)容由21ic獲得授權(quán)后發(fā)布，版權(quán)歸原作者所有，本平臺僅提供信息存儲服務(wù)。文章僅代表作者個人觀點，不代表本平臺立場，如有問題，請聯(lián)系我們，謝謝！