修改顺序#

对一个原子变量的所有修改操作总是存在一定的先后顺序, 且所有线程都认可这个顺序, 即使这些修改操作是在不同的线程中执行的. 这个所有线程一致同意的顺序就称为修改顺序 (modification order). 这意味着

• 两个修改操作不可能同时进行, 一定存在一个先后顺序. 这很容易理解, 因为这是原子操作必须保证的, 否则就有数据竞争的问题.
• 即使每次运行的修改顺序可能都不同, 但所有线程看到的修改顺序总是一致的. 如果线程 a 看到原子变量 x 由 1 变成 2, 那么线程 b 就不可能看到 x 由 2 变成 1.

无论使用哪种内存顺序, 原子变量的操作总能满足修改顺序一致性, 即使是最松散的 memory_order_relaxed. 我们来看一个例子

1
std::atomic<int> a{0};
2

3
void thread1() {
4
    for (int i = 0; i < 10; i += 2)
5
        a.store(i, std::memory_order_relaxed);
6
}
7

8
void thread2() {
9
    for (int i = 1; i < 10; i += 2)
10
        a.store(i, std::memory_order_relaxed);
11
}
12

13
void thread3(vector<int> *v) {
14
    for (int i = 0; i < 10; ++i)
15
        v->push_back(a.load(std::memory_order_relaxed));
16
}
17

18
void thread4(vector<int> *v) {
19
    for (int i = 0; i < 10; ++i)
20
        v->push_back(a.load(std::memory_order_relaxed));
21
}
22

23
int main() {
24
    vector<int> v3, v4;
25
    std::thread t1(thread1), t2(thread2), t3(thread3, &v3), t4(thread4, &v4);
26
    t1.join(), t2.join(), t3.join(), t4.join();
27

28
    for (int i : v3) cout << i << " ";
29
    cout << endl;
30
    for (int i : v4) cout << i << " ";
31
    cout << endl;
32
    return 0;
33
}

上面的代码创建了 4 个线程. thread1 和 thread2 分别将偶数和奇数依次写入原子变量 a, thread3 和 thread4 则读取它们. 最后输出 thread3 和 thread4 每次读取到的值. 程序运行的结果可能是这样的

1
1 8 7 7 7 9 9 9 9 9
2
0 2 8 8 8 7 9 9 9 9
3
-------------------
4
1 2 5 6 9 9 9 8 8 8
5
1 3 2 5 9 8 8 8 8 8

虽然每次运行的修改顺序不同, 各个线程也不太可能看到每次修改的结果, 但是它们看到的修改顺序是一致的. 例如 thread3 看到的顺序是 8 7 9, 那么thread4看到的顺序也是8 7 9. thread3看到的顺序是1 5 9 8 那么 thread4看到的顺序一样是1 5 9 8

指令重排#

1
int a, b;
2

3
void foo() {
4
    a = 42;
5
    b = a;
6

7
    assert(b == 42);
8
}

1
mov %eax, 42
2
mov (b), %eax
3
mov (a), %eax

1
a = 42; // (1)
2
cout << a << endl; // (2)

1
int data;
2
std::atomic_bool flag { false };
3

4
// Execute in thread A
5
void producer() {
6
    data = 42;  // (1)
7
    flag.store(true);  // (2)
8
}
9

10
// Execute in thread B
11
void consume() {
12
    while (!flag.load());  // (3)
13
    assert(data == 42);  // (4)
14
}

1
void thread1() {
2
    a += 1 // (1)
3
    unlock(); // (2)
4
}
5

6
void thread2() {
7
    lock(); // (3)
8
    cout << a << endl; // (4)
9
}

缓存一致性#

我们都知道二维数组横向遍历比纵向遍历要快。为什么？

• 我们知道有L1 L2 L3三级cache。然后才是内存。CPU需要把内存里的数据读到cache中。但是CPU为了最大化利用cache line的能力，一般会读取一个固定大小的数据区块。一般来说 L3 Cache 比 L1 Cache 和 L2 Cache 大很多，这是因为 L1 Cache 和 L2 Cache 都是每个 CPU 核心独有的，而 L3 Cache 是多个 CPU 核心共享的。

这也就是为什么连续内存操作会比较快，也是为什么内存对齐十分重要。因为如果起点在奇数位就会有二次操作。

CPU cache到内存的映射有三种：

• 直接映射
  • 直接映射通俗易懂。就是内存地址映射到的cache line是固定的。比较好找。但是问题在于这个数量非常少。如果多个数据抢占同一个cache line，就会发生cache频繁的换入换出。
• 全相连映射
  • 全相连映射的意思是任意一个内存地址可以映射到任意一个cache line。也就是见缝插针。问题在于在寻找一个内存地址是否已被映射的时候，需要遍历每一个cacheline
• 组相连映射
  • 组相连映射也就是组间采用直接映射，组内采用全相连映射。

MESI 协议#

MESI 协议其实是 4 个状态单词的开头字母缩写，分别是：

• Modified，已修改
• Exclusive，独占
• Shared，共享
• Invalidated，已失效

这四个状态来标记 Cache Line 四个不同的状态。

• 「已修改」状态就是我们前面提到的脏标记，代表该 Cache Block 上的数据已经被更新过，但是还没有写到内存里。
• 「已失效」状态，表示的是这个 Cache Block 里的数据已经失效了，不可以读取该状态的数据。
• 「独占」和「共享」状态都代表 Cache Block 里的数据是干净的，也就是说，这个时候 Cache Block 里的数据和内存里面的数据是一致性的。
  • 「独占」和「共享」的差别在于，独占状态的时候，数据只存储在一个 CPU 核心的 Cache 里，而其他 CPU 核心的 Cache 没有该数据。这个时候，如果要向独占的 Cache 写数据，就可以直接自由地写入，而不需要通知其他 CPU 核心，因为只有你这有这个数据，就不存在缓存一致性的问题了，于是就可以随便操作该数据。
  • 另外，在「独占」状态下的数据，如果有其他核心从内存读取了相同的数据到各自的 Cache ，那么这个时候，独占状态下的数据就会变成共享状态。
• 那么，「共享」状态代表着相同的数据在多个 CPU 核心的 Cache 里都有，所以当我们要更新 Cache 里面的数据的时候，不能直接修改，而是要先向所有的其他 CPU 核心广播一个请求，要求先把其他核心的 Cache 中对应的 Cache Line 标记为「无效」状态，然后再更新当前 Cache 里面的数据。

我们举个具体的例子来看看这四个状态的转换：

1. 当 A 号 CPU 核心从内存读取变量 i 的值，数据被缓存在 A 号 CPU 核心自己的 Cache 里面，此时其他 CPU 核心的 Cache 没有缓存该数据，于是标记 Cache Line 状态为「独占」，此时其 Cache 中的数据与内存是一致的；
2. 然后 B 号 CPU 核心也从内存读取了变量 i 的值，此时会发送消息给其他 CPU 核心，由于 A 号 CPU 核心已经缓存了该数据，所以会把数据返回给 B 号 CPU 核心。在这个时候， A 和 B 核心缓存了相同的数据，Cache Line 的状态就会变成「共享」，并且其 Cache 中的数据与内存也是一致的；
3. 当 A 号 CPU 核心要修改 Cache 中 i 变量的值，发现数据对应的 Cache Line 的状态是共享状态，则要向所有的其他 CPU 核心广播一个请求，要求先把其他核心的 Cache 中对应的 Cache Line 标记为「无效」状态，然后 A 号 CPU 核心才更新 Cache 里面的数据，同时标记 Cache Line 为「已修改」状态，此时 Cache 中的数据就与内存不一致了。
4. 如果 A 号 CPU 核心「继续」修改 Cache 中 i 变量的值，由于此时的 Cache Line 是「已修改」状态，因此不需要给其他 CPU 核心发送消息，直接更新数据即可。
5. 如果 A 号 CPU 核心的 Cache 里的 i 变量对应的 Cache Line 要被「替换」，发现 Cache Line 状态是「已修改」状态，就会在替换前先把数据同步到内存。

说完了MESI协议，回到我们Example 8.5的那张图。具体缓存一致性在哪儿出问题了？

假设在cache line中状态为共享，在某个核更新数据时候会向总线发送已失效消息以获取数据的所有权，其他消息得到此消息后更新相应cache line状态为已失效，并回复Invalidate Acknowledge消息。显然我们可以看到这个过程非常的繁琐，如果每个操作生效前都需要这么多操作那也太低效了，所以引入了Invaildate queue和Store Buffer，为的就是异步执行指令，提高以上过程的效率。

因为写入到Invaildate queue和Store Buffer的数据并不会被立即执行。在执行写操作的核会把数据写入store buffer，后面异步的刷新到cache line，当然也会广播失效消息。而当另一个执行读操作的核收到这个失效消息时，会把消息写入自身的Invalidate Queue中，随后异步将cache line设为失效状态。写操作的核在读取的时候会扫描store buffer，而这个执行读操作的核在读取数据的时候并不会扫描Invaildate queue，这意味着读操作可能会在一段时间内读到老旧数据。

首先process 0和process 1把1放入到地址_x和_y的内存上，但是此时可能这些数据还存在自己的store buffer中，也就是对方都还没意识到数据已经发生修改，然后执行操作r2和r4的操作，此时就发生脏读，导致 r2 = 0 且 r4 = 0这种奇怪的事情发生。

• 也就是在processor 1把y的值更改为1的时候，并没有直接写入内存。此时在processor 0眼里y还是0。所以r2就是0

https://mp.weixin.qq.com/s/Sz7QXx1h4sS7xWRUSP4ZCw

内存屏障#

经过上面的总结，我们可以得出结论。内存屏障存在的意义是在一定程度上避免缓存一致性所带来的问题和指令重排。

在广义角度上，Intel有三种内存模型：

SFENCE，LFENCE和MFENCE指令提供了一种性能高效的方式，可确保在产生弱排序结果的例程和使用该数据的例程之间load和store内存排序。 这些指令的功能如下：

• SFENCE：序列化(动词，理解为串行化) 程序指令流中，在SFENCE指令之前发生的所有 store（写）操作，但不影响 load（读）操作。
• LFENCE：序列化 程序指令流中，在LFENCE指令之前发生的所有 load（读）操作，但不影响 store（写）操作。
• MFENCE：序列化 程序指令流中，在MFENCE指令之前发生的所有 store 和 load 操作。

当然，还有一些其他操作含有内存屏障的作用

• 总线上的内存映射设备和其他I / O设备通常对其I / O缓冲区的写入顺序敏感。可以使用I / O指令（IN和OUT指令）对此类访问施加强的写入顺序，如下所示。在执行I / O指令之前，处理器将等待程序中所有先前的指令完成，并等待所有缓冲的写入操作耗尽到内存。只有指令提取和页表遍历可以传递I / O指令。直到处理器确定I / O指令已完成，后续指令的执行才开始。
• 多处理器系统中的同步机制可能取决于强大的内存排序模型。在这里，程序可以使用诸如XCHG指令或LOCK前缀之类的锁定指令，以确保原子地执行对存储器的读-修改-写操作。锁定操作通常类似于I / O操作，因为它们等待所有先前的指令完成并且等待所有缓冲的写操作排入内存。
• 程序同步也可以通过序列化指令执行（请参见第8.3节）。这些指令通常用于关键过程或任务边界，以在跳到新的代码段或上下文切换之前强制完成所有先前的指令。像I / O和锁定指令一样，处理器在执行序列化指令之前要等到所有先前的指令都已完成并且所有缓冲的写操作都已排入内存为止。

请注意，与CPUID指令相比，SFENCE，LFENCE和MFENCE指令提供了一种更有效的控制内存顺序的方法。

从上面，我们可以看出：内存屏障，带Lock或XCHG前缀的指令，I/O操作都会把数据载入内存，自然就不存在前面我们提到的脏读问题了。

我们一直以来提到的指令重排指的是运行时排序。编译器也会导致指令重排。这里更多的讨论见这里

内存模型（内存序）#

我们前面提到了程序运行时的指令重排，内存模型其实规定的就是这些指令的重排哪些排列顺序是正确的，也就是指明在特定要求下，哪些是可以出现的，哪些是不可以出现的。

事实上对于内存模型的描述我们可以从两个方面来看，一个是硬件角度的内存模型，也就是厂商给我们提供了怎样的一种一致性保证；还有一种是软件级别的内存模型，其实说直白一点就是一些高级语言给程序员提供的一致性保证，显然此时我们可以不必费尽心机去考虑代码如何适配不同的机器。

比如X86的强模型和ARM的弱模型，如果仅仅依靠硬件提供的内存屏障这个代码将非常难写， 因为不同硬件本身的提供的内存模型是不一样的，甚至有时操作也不相同。但是如果基于软件级别的内存模型，比如使用C++的内存模型（手段为内存序），那么编译器就会帮我们自动去适配不同的机器，因为这是语言保证的。

英特尔酷睿2双核，英特尔凌动，英特尔酷睿双核，奔腾4和P6家族处理器还使用处理器排序的内存排序模型，该模型可以进一步定义为“使用存储缓冲区转发进行写入排序”。 该模型的特征如下。 在用于定义为WB的内存区域的单处理器系统中，内存排序模型遵循以下原则（请注意，单处理器和多处理器系统的内存排序原则是从在以下环境中执行软件的角度编写的。其中术语“处理器”是指逻辑处理器。例如，支持多核和/或Intel超线程技术的物理处理器被视为多处理器系统。）

• 读操作之间无法排序

• 写操作不能和旧的读操作之间排序

• 写操作与写操作之间除了以下情况以外不能重新排序：

  • 带有non-temporal move指令的流存储（写入）（MOVNTI, MOVNTQ, MOVNTDQ, MOVNTPS, 和 MOVNTPD）

  • 串操作

• 执行CLFLUSH指令不能重新排序对存储器的写操作。 可以通过执行CLFLUSHOPT指令的执行来重新排序写操作，该指令将刷新除正在写入的高速缓存行以外的其他高速缓存行。 CLFLUSH指令的执行不会相互重新排序。 访问不同缓存行的CLFLUSHOPT的执行可能会相互重新排序。 CLFLUSHOPT的执行可以与访问不同缓存行的CLFLUSH的执行重新排序。

• 读取可能会与不同地址的较旧写入重新排序，但对不同地址的较旧写入则不会重新排序。（store load重排）

• 读写操作不能与IO操作，带LOCK的指令，序列化指令重排序。（上面曾提到过这个问题）

• 读操作不能越过前面的LFENCE和MFENCE操作

• 写操作和CLFLUSH和CLFLUSHOPT的执行不能越过前面的LFENCE，SFENCE和MFENCE指令。

• LFENCE不能越过前面的读操作

• SFENCE不能越过前面的写操作

• MFENCE不能越过前面的读写操作以及CLFLUSH和CLFLUSHOPT的执行。

https://zhuanlan.zhihu.com/p/269221065?utm_id=0

https://blog.51cto.com/u_15703183/5464436

https://blog.csdn.net/qq_22642239/article/details/114022306

https://redrain.blog.csdn.net/article/details/111327141

C++中的内存序----三（四）种模型和六种枚举值#

std::memory_order 指定内存访问，包括常规的非原子内存访问，如何围绕原子操作排序。在没有任何制约的多处理器系统上，多个线程同时读或写数个变量时，一个线程能观测到变量值更改的顺序不同于另一个线程写它们的顺序。其实，更改的顺序甚至能在多个读取线程间相异。一些类似的效果还能在单处理器系统上出现，因为内存模型允许编译器变换。

注意，其实内存序并不能简单描述成为禁止某某操作排到某某操作后面。因为就算单纯禁止重排，也有可能发生我们提过的缓存一致性问题。所以说，应该用可见性这个词。可见性这个词包含了描述重排和缓存一致性的情况。所以说，我们说某某操作现在是可见的，表明了确实我们保证操作正确。也就是不仅正确处理了重排，也正确处理了缓存一致性问题。

1
std::atomic<bool> x{false}, y{false};
2

3
void thread1() {
4
    x.store(true, std::memory_order_seq_cst); // (1)
5
}
6

7
void thread2() {
8
    y.store(true, std::memory_order_seq_cst); // (2)
9
}

1
std::atomic<int> z{0};
2

3
void read_x_then_y() {
4
    while (!x.load(std::memory_order_seq_cst)); // (3)
5
    if (y.load(std::memory_order_seq_cst)) ++z; // (4)
6
}
7

8
void read_y_then_x() {
9
    while (!y.load(std::memory_order_seq_cst)); // (5)
10
    if (x.load(std::memory_order_seq_cst)) ++z; // (6)
11
}
12

13
int main() {
14
    std::thread a(thread1), b(thread2), c(read_x_then_y), d(read_y_then_x);
15
    a.join(), b.join(), c.join(), d.join();
16
    assert(z.load() != 0); // (7)
17
}

1
std::atomic<bool> x{false}, y{false};
2

3
void thread1() {
4
    x.store(true, std::memory_order_relaxed); // (1)
5
    y.store(true, std::memory_order_release); // (2)
6
}
7

8
void thread2() {
9
    while (!y.load(std::memory_order_acquire)); // (3)
10
    assert(x.load(std::memory_order_relaxed)); // (4)
11
}

1
void thread1() {
2
    x.store(true, std::memory_order_release); // (1)
3
}
4

5
void thread2() {
6
    y.store(true, std::memory_order_release); // (2)
7
}
8

9
void read_x_then_y() {
10
    while (!x.load(std::memory_order_acquire)); // (3)
11
    if (y.load(std::memory_order_acquire)) ++z; // (4)
12
}
13

14
void read_y_then_x() {
15
    while (!y.load(std::memory_order_acquire)); // (5)
16
    if (x.load(std::memory_order_acquire)) ++z; // (6)
17
}

1
// Thread 1:
2
r1 = y.load(std::memory_order_relaxed); // A
3
x.store(r1, std::memory_order_relaxed); // B
4
// Thread 2:
5
r2 = x.load(std::memory_order_relaxed); // C
6
y.store(42, std::memory_order_relaxed); // D

1
std::atomic<bool> x{false}, y{false};
2

3
void thread1() {
4
    x.store(true, std::memory_order_relaxed); // (1)
5
    y.store(true, std::memory_order_relaxed); // (2)
6
}

1
void thread2() {
2
    while (!y.load(std::memory_order_relaxed)); // (3)
3
    assert(x.load()); // (4)
4
}

memory_order_acquire和memory_order_release 如何搭配使用#

往往memory_order_acquire和memory_order_release是配合着一起使用的：

1. 线程1使用memory_order_release写入原子变量x
2. 线程2使用memory_order_acquire读出原子变量x

所有在线程1上，在写入x之前的写入操作，都将在线程2上，在读出x之后，被看到。使用单向“加载”+单向“释放”协议的场景往往是：

1. 线程1，写入一些实际数据，接着通过将原子变量x设置为某个值A（通过使用memory_order_release写入原子变量x）来“发布”这些数据。
2. 线程2，通过读取并判断x已被设置为A（通过使用memory_order_acquire来读取原子变量x），进而读取线程1实际“发布”的那些数据

必须操作的是同一个原子变量。

如上图所示，thread_1在release写入x(值:A)之前，写入了待发布的a,b的数据，而thread_2，将在acquire读出x且为A之后，将读到thread_1发布的a,b的数据。同时，我们可以注意到，在thread_2上，在acquire读出x之前，如果对a进行读操作，我们是无法确认读到的a一定会thread_1在之前最后写入的a，这里的顺序是不会被保证的，重排是被允许的。同时，在之后，读取c，读到的是否为thread_1最后写入的c，也是不确定的，因为，在x写入之后，thread_1上又出现了一次写入，而如果在此之前，还有一次写入， 这两次写入之间，是不存在限制，可能会被重排的。

thread_1上有了release_store，对于a，b的写入就一定会在x的改变之前，在thread_2上，就不会出现类似读出c，的不确定性。thread_2上有了acquire_load，右侧的读出a，就不会被重排读到左侧，而左侧读出a的不确定性，也不存在。thread_1卡住的是：对于数据a，b的写入不能排到x的写入之后，thread_2卡住的，是对于数据a，b的读取，不能排到读取x之前，这样，就保证了数据a，b，与”信号量”x，之间，在thread_1, thread_2上的同步关系。

Release sequences 释放序列#

到目前为止我们看到的, 无论是 sequencial consistent 还是 release-acquire, 要想实现 synchronizes-with 的关系, acquire 操作必须在同一个原子变量上读到 release 操作的写入的值. 如果 acquire 操作没有读到 release 操作写入的值, 那么它俩之间通常没有 synchronizes-with 的关系. 例如

1
std::atomic<int> x{0}, y{0};
2

3
void thread1() {
4
    x.store(1, std::memory_order_relaxed); // (1)
5
    y.store(1, std::memory_order_release); // (2)
6
}
7

8
void thread2() {
9
    y.store(2, std::memory_order_release); // (3)
10
}
11

12
void thread3() {
13
    while (!y.load(std::memory_order_acquire)); // (4)
14
    assert(x.load(std::memory_order_relaxed) == 1); // (5)
15
}

上面的例子中, 只要 y 的值非 0 循环 (4) 就会退出. 当它退出时, 有可能读到 (2) 写入的值, 也有可能读到 (3) 写入的值. 如果是后者, 则只能保证 (3) “synchronizes-with” (4), 不能保证与 (2) 与 (4) 之间有同步关系. 因此 (5) 处的断言就有可能失败.

但并不是只有在 acquire 操作读取到 release 操作写入的值时才能构成 synchronizes-with 关系. 为了说这种情况, 我们需要引入 release sequence 这个概念.

针对一个原子变量 M 的 release 操作 A 完成后, 接下来 M 上可能还会有一连串的其他操作. 如果这一连串操作是由

• 同一线程上的写操作, 或者
• 任意线程上的 read-modify-write 操作

这两种构成的, 则称这一连串的操作为以 release 操作 A 为首的 release sequence. 这里的写操作和 read-modify-write 操作可以使用任意内存顺序.

如果一个 acquire 操作在同一个原子变量上读到了一个 release 操作写入的值, 或者读到了以这个 release 操作为首的 release sequence 写入的值, 那么这个 release 操作 “synchronizes-with” 这个 acquire 操作. 我们来看个例子

1
std::vector<int> data;
2
std::atomic<int> flag{0};
3

4
void thread1() {
5
    data.push_back(42); // (1)
6
    flag.store(1, std::memory_order_release); // (2)
7
}
8

9
void thread2() {
10
    int expected = 1;
11
    while (!flag.compare_exchange_strong(expected, 2, std::memory_order_relaxed)) // (3) 注意此处使用了宽松
12
        expected = 1;
13
}
14

15
void thread3() {
16
    while (flag.load(std::memory_order_acquire) < 2); // (4)
17
    assert(data.at(0) == 42); // (5)
18
}

上面的例子中, (3) 处的 compare_exchange_strong 是一种 RMW 操作, 它判断原子变量的值是否与期望的值 (第一个参数) 相等, 如果相等则将原子变量设置成目标值 (第二个参数) 并返回 true, 否则将第一个参数 (引用传递) 设置成原子变量当前值并返回 false. 操作 (3) 会一直循环检查, 当 flag 当值为 1 时, 将其替换成 2. 所以 (3) 属于 (2) 的 release sequence. 而循环 (4) 退出时, 它已经读到了 (3) 写入的值, 也就是 release 操作 (2) 为首的 release sequence 写入的值. 所以有 (2) “synchronizes-with” (4). 因此 (1) “happens-before” (5), (5) 处的断言不会失败.

注意 (3) 处的 compare_exchange_strong 的内存顺序是 memory_order_relaxed, 所以 (2) 与 (3) 并不构成 synchronizes-with 的关系. 也就是说, 当循环 (3) 退出时, 并不能保证 thread2 能读到 data.at(0) 为 42. 但是 (3) 属于 (2) 的 release sequence, 当 (4) 以 memory_order_acquire 的内存顺序读到 (2) 的 release sequence 写入的值时, 可以与 (2) 构成 synchronizes-with 的关系

注意, 这种只是一种概念. 依赖于代码的正确性. 同时, 我们说 “当循环 (3) 退出时, 并不能保证 thread2 能读到 data.at(0) 为 42”的原因是 这个插入操作由于缓存一致性的原因, 并不保证被刷新到thread2的cache内. 尽管从逻辑上讲, 当flag从1变为2的时候, 写入操作已经发生了, 但是这个时候这个写入并不一定保证对thread2可见. 当然了, 假设这个原子变量和写入数据在一个cache line中, 这个操作可能对thread2是可见的

如何理解内存序和锁之间的联系？#

多线程编程，临界区是一个很重要的概念。我们对此再做进一步的认识。

对于临界区区内的语句，显而易见，我们不能将其移出临界区，如下图所示，编译器和CPU都不会做这种移出临界区的优化：

但我们可以将临界区区外的代码移进来，如下图所示

从上面两张图我们可以看出，lock和unlock可以看作两个单方向的屏障，lock对应的屏障，只允许代码往下方向移动，而`unlock则只允许上方向移动。

所以我们是不是发现：memory_order_acquire类似lock，memory_order_release类似unlock，这两个都是单方向的屏障（One-way Barriers: acquire barrier, release barrier）。

所以借助内存屏障+原子变量，在比互斥锁更底层的层面，我们也能实现线程间同步。比如下图的例子：

p原子变量，当线程2看到p为非空时，后续的r1 = A语句可以看到线程1对A的写操作结果。这是因为线程1对p的store操作Synchronizes-with线程2对p的load操作，这样加之Happens-before关系，我们实现了线程间同步。值得一提的是，线程1中，A=B+1Happens-before B = 1，但B = 1可能先执行，但线程1对A的写操作的结果，依旧能正确地被线程2中int r1 = A语句读取。

换句话说，我们利用了memory_order_release，使得针对A和B的写入一定会发生在写入原子变量p之前。我们利用了memory_order_acquire使得针对A和x的读取一定发生在读取原子变量p之前。

有人也许会问，用非原子变量难道不能实现Synchronizes-with关系？首先，非原子变量，显然不能被多个线程同时读写，再者，其无法提供内存屏障，不要忘了前文重排的例子，试想，若线程1中A和B的写入操作被重排到了p.store的后面，且即使替换p.store的非原子变量操作在多线程下可以正确执行，但此时int r1 = A能读取到正确的值吗？

同步的传递性和acquire搭配release的小例子#

1
atomic<int> data[5];
2
atomic<bool> sync1(false), sync2(false);
3

4
void thread_1_func(){
5
  data[0].store(1, memory_order_relaxed);
6
  data[1].store(2, memory_order_relaxed);
7
  data[2].store(3, memory_order_relaxed);
8
  data[3].store(4, memory_order_relaxed);
9
  data[4].store(5, memory_order_relaxed);
10
  sync1.store(true, memory_order_release); //注释1
11
}
12

13
void thread_2_func(){
14
  while(!sync1.load(memory_order_acquire)); //注释2
15
  sync2.store(true, memory_order_release); //注释3
16
}
17

18
void thread_3_func(){
19
  while(!sync2.load(memory_order_acquire)); //注释4
20
  assert(data[0].load(memory_order_relaxed) == 1);
21
  assert(data[1].load(memory_order_relaxed) == 2);
22
  assert(data[2].load(memory_order_relaxed) == 3);
23
  assert(data[3].load(memory_order_relaxed) == 4);
24
  assert(data[4].load(memory_order_relaxed) == 5);
25
  cout << "all success" << endl;
26
}
27

28
int main(){
29
  thread th1(thread_1_func);
30
  thread th2(thread_2_func);
31
  thread th3(thread_3_func);
32

33
  th1.join();
34
  th2.join();
35
  th3.join();
36
  return 0;
37
}

• 在func1当中，我们的数据存储使用了relaxed，所以可能是乱序，但是无关紧要。我们的核心目的是保证thread3能看到thread1中存储的全部数据。所以：
• 在func1中，我们针对sync1的写入使用了release。也就是说，在把sync1修改为true的这个操作之前，可以保证前面的操作全部完成，不会重排到这个操作之后，同时也保证缓存一致性，也就是之前的操作全部对其他线程可见。
• 在func2中，我们针对sync1的读取使用了acquire操作。也就是说，在读取到sync1是true之前，任何操作不能被重排到该操作之前。也就保证了针对sync2的修改一定发生在发现sync1是true之后。
• 随后在func2中，我们针对sync3的写入使用了release。原因同上。
• 在func3中，针对sync3的读取使用了acquire，原因同上。
• 最后在assert中，乱序可能发生，但是无所谓。

• acquire和release的语义可以形象理解为：如果我不释放（release），你的请求（acquire）必须等待，直到我释放为止。

atomic_thread_fence分类和效果#

在C++ 11及之后的标准里，除了利用原子操作指定内存序，还定义了单独使用memory fence（std::atomic_thread_fence）的方式，fence可以和原子操作组合进行同步，也可以fence之间进行同步，fence不光可以不依赖原子操作进行同步，而且相比较于同样memory order的原子操作，具有更强的内存同步效果

和atomic变量类似，atomic_thread_fence也可以指定六种内存序，指定不同内存序的fence可以分为以下几类： （1） std::atomic_thread_fence(memory_order_relaxed)，没有任何效果。 （2） std::atomic_thread_fence(memory_order_acquire) 和 std::atomic_thread_fence(memory_order_consume) 属于acquire fence。 （3）std::atomic_thread_fence(memory_order_release)属于release fence。 （4）std::atomic_thread_fence(memory_order_acq_rel)既是acquire fence 也是release fence，为了方便这里称为full fence。 （5）std::atomic_thread_fence(memory_order_seq_cst)额外保证有单独全序的full fence。

也就是说，如果不考虑单独全序，那么有release fence、acquire fence 和full fence三种。下面就根据以前介绍过的四种重排来介绍下这三种fence的效果。

不同类型的Fence对于乱序的保护是不一样的。我们可以将读和写的交错分成下面四种情况：

• Load-Load：读接着读
• Load-Store：先读后写
• Store-Load：先写后读
• Store-Store：写接着写