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

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

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

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

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

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

一個(gè)良好的memory model定義包含3個(gè)方面：

◆ Atomic Operations

◆ Partial order of operations

◆ Visable effects of operations

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

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

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

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

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

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

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

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

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

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

sequenced-before

同一個(gè)線程之內(nèi)，語句A的執(zhí)行順序在語句B前面，那么就成為A sequenced-before B。它不僅僅表示兩個(gè)操作之間的先后順序，還表示了操作結(jié)果之間的可見性關(guān)系。兩個(gè)操作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)系滿足傳遞性、非自反性和非對(duì)稱性。happens before包含了inter-thread happens before和synchronizes-with兩種關(guān)系。

synchronizes-with

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

Carries dependency

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

了解了上面一些基本概念，下面我們來一起學(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ī)則可以簡(jiǎn)要描述為：

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

2.1 memory order releaxed

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

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

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

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

2.2 memory order consume

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

b = *a;
c = *b

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

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

• 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)系。在這個(gè)關(guān)系下：線程A中所有發(fā)生在release x之前的值的寫操作， 對(duì)線程B的acquire x之后的任何操作都可見。

上面的例子中：

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

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

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

2.4 memory order release

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

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

2.5 memory order acq_rel

acq_rel是acquire和release的疊加。

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

2.6 memory order seq_cst

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

2.7 Relationship with volatile

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

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

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

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

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

看一個(gè)例子，執(zhí)行下面的并發(fā)程序，不出意外的話，你不會(huì)得到一個(gè)為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)我們?cè)谡務(wù)?memory order 的時(shí)候，我們?cè)谡務(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循序漸進(jìn)

13. Memory Models for C/C++ Programers

14. Memory Consistency Models: A Tutorial

(END)

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