現(xiàn)代計算機(jī)體系結(jié)構(gòu)上,CPU執(zhí)行指令的速度遠(yuǎn)遠(yuǎn)大于CPU訪問內(nèi)存的速度,于是引入Cache機(jī)制來加速內(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)存模型表達(dá)為“內(nèi)存順序模型”可能更加貼切一點。
一個良好的memory model定義包含3個方面:
◆ Atomic Operations
◆ Partial order of operations
◆ Visable effects of operations
這里要強(qiáng)調(diào)的是:我們這里所說的內(nèi)存模型和CPU的體系結(jié)構(gòu)、編譯器實現(xiàn)和編程語言規(guī)范3個層面都有關(guān)系。
首先,不同的CPU體系結(jié)構(gòu)內(nèi)存順序模型是不一樣的,但大致分為兩種:
x86_64和Sparc是強(qiáng)順序模型(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),是把是否要求強(qiáng)制順序這個要求直接交給程序員的方法。換句話說,CPU不去保證這個順序模型(除非他們在一個CPU上就有依賴), 程序員要主動插入內(nèi)存屏障指令來強(qiáng)化這個“可見性”[4]。ARMv8,PowerPC和MIPS等體系結(jié)構(gòu)都是弱內(nèi)存模型。每種弱內(nèi)存模型的體系架構(gòu)都有自己的內(nèi)存屏障指令,語義也不完全相同。弱內(nèi)存模型下,硬件實現(xiàn)起來相對簡單,處理器執(zhí)行的效率也高, 只要沒有遇到顯式的屏障指令,CPU可以對局部指令進(jìn)行reorder以提高執(zhí)行效率。
對于多線程程序開發(fā)來說,對并發(fā)的數(shù)據(jù)訪問我們一般到做同步操作, 可以使用mutex,semaphore,conditional等重量級方案對共享數(shù)據(jù)進(jìn)行保護(hù)。但為了實現(xiàn)更高的并發(fā),需要使用內(nèi)存共享變量做通信(Message Passing), 這就對程序員的要求很高了,程序員必須時時刻刻必須很清楚自己在做什么, 否則寫出來的程序的執(zhí)行行為會讓人很是迷惑!值得一提的是,并發(fā)雖好,如果能夠簡單粗暴實現(xiàn),就不要搞太多投機(jī)取巧!要實現(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)秀~
C11/C++11使用memory order來描述memory model, 而用來聯(lián)系memory order的是atomic變量, atomic操作可以用load()和release()語義來描述。一個簡單的atomic變量賦值可描述為:
為了更好地描述內(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)系強(qiáng)調(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),表達(dá)式A sequenced-before 表達(dá)式B,并且表達(dá)式B的值是受表達(dá)式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)系的操作進(jì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")永遠(yuǎn)不會失敗,但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的約束是最強(qiáng)的,這意味著要犧牲性能為代價。
2.7 Relationship with volatile
人的一生總是充滿了疑惑。
可能你會思考?volatile關(guān)鍵字能夠防止指令被編譯器優(yōu)化,那它能提供線程間(inter-thread)同步語義嗎?答案是:不能!??!
-
盡管volatile能夠防止單個線程內(nèi)對volatile變量進(jìn)行reorder,但多個線程同時訪問同一個volatile變量,線程間是完全不提供同步保證。
-
而且,volatile不提供原子性!
-
并發(fā)的讀寫volatile變量是會產(chǎn)生數(shù)據(jù)競爭的,同時non volatile操作可以在volatile操作附近自由地reorder。
看一個例子,執(zhí)行下面的并發(fā)程序,不出意外的話,你不會得到一個為0的結(jié)果。
3. Reference
-
The C/C++ Memory Model: Overview and Formalization
-
知乎專欄:如何理解C++的6種memory order
-
理解 C++ 的 Memory Order
-
理解弱內(nèi)存順序模型
-
當(dāng)我們在談?wù)?memory order 的時候,我們在談?wù)撌裁?
-
https://en.cppreference.com/w/cpp/atomic/memory_order
-
Youtube: Atomic’s memory orders, what for? - Frank Birbacher [ACCU 2017]
-
C++11中的內(nèi)存模型下篇 - C++11支持的幾種內(nèi)存模型
-
memory ordering, Gavin's blog
-
c++11 內(nèi)存模型解讀
-
memory barriers in c, MariaDB FOUNDATION, pdf
-
C++ memory order循序漸進(jìn)
-
Memory Models for C/C++ Programers
-
Memory Consistency Models: A Tutorial
(END)
免責(zé)聲明:本文內(nèi)容由21ic獲得授權(quán)后發(fā)布,版權(quán)歸原作者所有,本平臺僅提供信息存儲服務(wù)。文章僅代表作者個人觀點,不代表本平臺立場,如有問題,請聯(lián)系我們,謝謝!