現代計算機體系結構上，CPU執行指令的速度遠遠大於CPU訪問內存的速度，於是引入Cache機制來加速內存訪問速度。除了Cache以外，分支預測和指令預取也在很大程度上提升了CPU的執行速度。隨着SMP的出現，多線程編程模型被廣泛應用，在多線程模型下對共享變量的訪問變成了一個複雜的問題。於是我們有必要了解一下內存模型，這是多處理器架構下併發編程裏必須掌握的一個基礎概念。

1. 什麼是內存模型？

到底什麼是內存模型呢？看到有兩種不同的觀點：

A：內存模型是從來描述編程語言在支持多線程編程中對共享內存訪問的順序。
B：內存模型的本質是指在單線程情況下CPU指令在多大程度上發生指令重排(reorder)[1]。

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

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

Atomic Operations
Partial order of operations
Visable effects of operations

這裏要強調的是：我們這裏所說的內存模型和CPU的體系結構、編譯器實現和編程語言規範3個層面都有關係。

首先，不同的CPU體系結構內存順序模型是不一樣的，但大致分爲兩種：

Architecture	Memory Model
x86_64	Total Store Order
Sparc	Total Store Order
ARMv8	Weakly Ordered
PowerPC	Weakly Ordered
MIPS	Weakly Ordered

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

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

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

其次，不同的編程語言對內存模型都有自己的規範，例如：C/C++和Java等不同的編程語言都有定義內存模型相關規範。

2011年發佈的C11/C++11 ISO Standard爲我們帶來了memory order的支持，引用C++11裏的一段描述：

The memory model means that C++ code now has a standardized
library to call regardless of who made the compiler and on
what platform it's running. There's a standard way to control
how different threads talk to the processor's memory.[7]

memory order的問題就是因爲指令重排引起的, 指令重排導致原來的內存可見順序發生了變化, 在單線程執行起來的時候是沒有問題的, 但是放到多核/多線程執行的時候就出現問題了, 爲了效率引入的額外複雜邏輯的的弊端就出現了[8]。

C++11引入memory order的意義在於我們現在有了一個與運行平臺無關和編譯器無關的標準庫，讓我們可以在high level languange層面實現對多處理器對共享內存的交互式控制。我們的多線程終於可以跨平臺啦！我們可以藉助內存模型寫出更好更安全的併發代碼。真棒，簡直不要太優秀~

C11/C++11使用memory order來描述memory model，而用來聯繫memory order的是atomic變量， atomic操作可以用load()和release()語義來描述。一個簡單的atomic變量賦值可描述爲：

 atomic_var1.store (atomic_var2.load()); // atomic variables
     vs
 var1 = var2;                            // regular variables

爲了更好地描述內存模型，有4種關係術語需要了解一下。

sequenced-before

同一個線程之內，語句A的執行順序在語句B前面，那麼就成爲A sequenced-before B。它不僅僅表示兩個操作之間的先後順序，還表示了操作結果之間的可見性關係。兩個操作A和操作B，如果有A sequenced-before B，除了表示操作A的順序在B之前，還表示了操作A的結果操作B可見。例如：語句A是sequenced-before語句B的。

r2 = x.load(std::memory_order_relaxed); // A
y.store(42, std::memory_order_relaxed); // B

happens-before

happens-before關係表示的不同線程之間的操作先後順序。如果A happens-before B，則A的內存狀態將在B操作執行之前就可見。happends-before關係滿足傳遞性、非自反性和非對稱性。happens before包含了inter-thread happens before和synchronizes-with兩種關係。

synchronizes-with

synchronizes-with關係強調的是變量被修改之後的傳播關係（propagate），即如果一個線程修改某變量的之後的結果能被其它線程可見，那麼就是滿足synchronizes-with關係的[9]。另外synchronizes-with可以被認爲是跨線程間的happends-before關係。顯然，滿足synchronizes-with關係的操作一定滿足happens-before關係了。

Carries dependency

同一個線程內，表達式A sequenced-before 表達式B，並且表達式B的值是受表達式A的影響的一種關係，稱之爲"Carries dependency"。這個很好理解，例如：

int *a = &var1;
int *b = &var2;
c = *a + *b;

瞭解了上面一些基本概念，下面我們來一起學習一下內存模型吧。

2. C11/C++11內存模型

C/C++11標準中提供了6種memory order，來描述內存模型[6]:

enum memory_order {
    memory_order_relaxed,
    memory_order_consume,
    memory_order_acquire,
    memory_order_release,
    memory_order_acq_rel,
    memory_order_seq_cst
};

每種memory order的規則可以簡要描述爲：

枚舉值	定義規則
memory_order_relaxed	不對執行順序做任何保證
memory_order_consume	本線程中，所有後續的有關本原子類型的操作，必須在本條原子操作完成之後執行
memory_order_acquire	本線程中，所有後續的讀操作必須在本條原子操作完成後執行
memory_order_release	本線程中，所有之前的寫操作完成後才能執行本條原子操作
memory_order_acq_rel	同時包含memory_order_acquire和memory_order_release標記
memory_order_seq_cst	全部存取都按順序執行

下面我們來舉例一一說明，扒開內存模型的神祕面紗。

2.1 memory order releaxed

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

                   std::atomic<int> x = 0;     // global variable
                   std::atomic<int> y = 0;     // global variable
		  
Thread-1:                                  Thread-2:
r1 = y.load(memory_order_relaxed); // A    r2 = x.load(memory_order_relaxed); // C
x.store(r1, memory_order_relaxed); // B    y.store(42, memory_order_relaxed); // D

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

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

#include <cassert>
#include <vector>
#include <iostream>
#include <thread>
#include <atomic>

std::atomic<int> cnt = {0};
void f()
{
    for (int n = 0; n < 1000; ++n) {
        cnt.fetch_add(1, std::memory_order_relaxed);
    }
}
int main()
{
    std::vector<std::thread> v;
    for (int n = 0; n < 10; ++n) {
        v.emplace_back(f);
    }
    for (auto& t : v) {
        t.join();
    }
    assert(cnt == 10000);    // never failed
    return 0;
}

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

2.2 memory order consume

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

b = *a;
c = *b

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

#include <thread>
#include <atomic>
#include <cassert>
#include <string>

std::atomic<std::string*> ptr;
int data;

void producer()
{
    std::string* p  = new std::string("Hello");
    data = 42;
    ptr.store(p, std::memory_order_release);
}

void consumer()
{
    std::string* p2;
    while (!(p2 = ptr.load(std::memory_order_consume)))
        ;
    assert(*p2 == "Hello");  // never fires: *p2 carries dependency from ptr
    assert(data == 42);      // may or may not fire: data does not carry dependency from ptr
}

int main()
{
    std::thread t1(producer);
    std::thread t2(consumer);
    t1.join();
    t2.join();
}

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

p2和ptr直接有依賴關係，但data和ptr沒有直接依賴關係，
儘管線程1中data賦值在ptr.store()之前，線程2看到的data的值還是不確定的。

2.3 memory order acquire

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

#include <thread>
#include <atomic>
#include <cassert>
#include <string>
#include <iostream>

std::atomic<bool> ready{ false };
int data = 0;
std::atomic<int> var = {0};

void sender()
{
    data = 42;                                              // A
    var.store(100, std::memory_order_relaxed);              // B
    ready.store(true, std::memory_order_release);           // C
}
void receiver()
{
    while (!ready.load(std::memory_order_acquire))          // D
        ;
    assert(data == 42);  // never failed                    // E
    assert(var == 100);  // never failed                    // F
}

int main()
{
    std::thread t1(sender);
    std::thread t2(receiver);
    t1.join();
    t2.join();
}

上面的例子中：

sender線程中data = 42是sequence before原子變量ready的
sender和receiver在C和D處發生了同步
線程sender中C之前的所有讀寫對線程receiver都是可見的顯然， release和acquire組合在一起比release和consume組合更加Strong！

2.4 memory order release

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

這裏就不用展開囉裏囉嗦了。

2.5 memory order acq_rel

acq_rel是acquire和release的疊加。中文不知道該咋描述好：

A read-modify-write operation with this memory order is both an acquire operation and a release operation. No memory reads or writes in the current thread can be reordered before or after this store. All writes in other threads that release the same atomic variable are visible before the modification and the modification is visible in other threads that acquire the same atomic variable.

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

這裏是一個例子，關於爲什麼要有acq_rel可以參考一下：

#include <thread>
#include <atomic>
#include <cassert>
#include <vector>
 
std::vector<int> data;
std::atomic<int> flag = {0};
 
void thread_1()
{
    data.push_back(42);
    flag.store(1, std::memory_order_release);
}
 
void thread_2()
{
    int expected=1;
    while (!flag.compare_exchange_strong(expected, 2, std::memory_order_acq_rel)) {
        expected = 1;
    }
}
 
void thread_3()
{
    while (flag.load(std::memory_order_acquire) < 2)
        ;
    assert(data.at(0) == 42); // will never fire
}
 
int main()
{
    std::thread a(thread_1);
    std::thread b(thread_2);
    std::thread c(thread_3);
    a.join(); b.join(); c.join();
}

2.6 memory order seq_cst

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

        atomic int x (0);               atomic int y (0);
    x. store (1, seq cst );     ||      y. store (1, seq cst );
    int r1 = y.load( seq cst ); ||      int r2 = x.load( seq cst );
                assert (r1 == 1 || r2 == 1);

下面是一個seq_cst的實例：

#include <thread>
#include <atomic>
#include <cassert>
 
std::atomic<bool> x = {false};
std::atomic<bool> y = {false};
std::atomic<int> z = {0};
 
void write_x()
{
    x.store(true, std::memory_order_seq_cst);
}
 
void write_y()
{
    y.store(true, std::memory_order_seq_cst);
}
 
void read_x_then_y()
{
    while (!x.load(std::memory_order_seq_cst))
        ;
    if (y.load(std::memory_order_seq_cst)) {
        ++z;
    }
}
 
void read_y_then_x()
{
    while (!y.load(std::memory_order_seq_cst))
        ;
    if (x.load(std::memory_order_seq_cst)) {
        ++z;
    }
}
 
int main()
{
    std::thread a(write_x);
    std::thread b(write_y);
    std::thread c(read_x_then_y);
    std::thread d(read_y_then_x);
    a.join(); b.join(); c.join(); d.join();
    assert(z.load() != 0);  // will never happen
}

2.7 Relationship with volatile

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

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

儘管volatile能夠防止單個線程內對volatile變量進行reorder，但多個線程同時訪問同一個volatile變量，線程間是完全不提供同步保證。
而且，volatile不提供原子性！
併發的讀寫volatile變量是會產生數據競爭的，同時non volatile操作可以在volatile操作附近自由地reorder。

看一個例子，執行下面的併發程序，不出意外的話，你不會得到一個爲0的結果。

#include <thread>
#include <iostream>

volatile int count = 0;

void increase() {
    for (int i = 0; i < 1000000; i++) {
        count++;
    }
}

void decrease() {
    for (int i = 0; i < 1000000; i++) {
        count--;
    }
}

int main() {
    std::thread t1(increase);
    std::thread t2(decrease);
    t1.join();
    t2.join();
    std::cout << count << std::endl;
}

3. Reference

The C/C++ Memory Model: Overview and Formalization
知乎專欄：如何理解C++的6種memory order
理解 C++ 的 Memory Order
理解弱內存順序模型
當我們在談論 memory order 的時候，我們在談論什麼
https://en.cppreference.com/w/cpp/atomic/memory_order
Youtube: Atomic’s memory orders, what for? - Frank Birbacher [ACCU 2017]
C++11中的內存模型下篇 - C++11支持的幾種內存模型
memory ordering, Gavin's blog
c++11 內存模型解讀
memory barriers in c, MariaDB FOUNDATION, pdf
C++ memory order循序漸進
Memory Models for C/C++ Programers
Memory Consistency Models: A Tutorial

(END)

Linux閱碼場原創精華文章彙總

更多精彩，盡在"Linux閱碼場"，掃描下方二維碼關注

深入理解C11/C++11內存模型

happens-before

2.3 memory order acquire

2.4 memory order release

2.5 memory order acq_rel

2.6 memory order seq_cst

2.7 Relationship with volatile

3. Reference

(END)

7大亮點功能上線！物聯網操作系統一站式開發工具RT-Thread Studio來襲

宋寶華： kvmalloc ——倚天劍屠龍刀兩大神器合體？

混亂的Linux內核實時線程優先級

深入理解C11/C++11內存模型

Linux內核態缺頁會發生什麼 - 玩轉Exception fixup表

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結