🌶️ 内存序 §

relaxed 内存序 §

std::memory_order_relaxed 是 C++ 11 中内存序要求最低的内存序，其本质就是原子操作。如前文所述，原子操作保证了数据的一致性和指令的不可分割性，但并没有保证指令的执行顺序。由于所有的 CPU 都必须满足数据一致性，此外像 load、store 这类基础的指令天然就应具备不可分割性。因此，市面主流的 CPU 架构的 load、store 指令都满足 std::memory_order_relaxed 的要求。不过，不满足不可分割性的指令也是存在的，比如 x86 中的 xadd 指令在未加 lock 前缀的情况下就会被分割为 load、add、store 三条指令执行，这时就不满足 std::memory_order_relaxed 的要求了，请看下例：

#include <chrono>
#include <thread>
#include <iostream>

alignas(64) std::uint64_t unlocked_counter = 0;
alignas(64) std::uint64_t locked_counter = 0;

void worker_locked(std::uint64_t iters) {
    for (std::uint64_t i = 0; i < iters; i++) {
        __asm {
            mov eax, 1
            lock xadd dword ptr locked_counter, eax
        }
    }
}

void worker_unlocked(std::uint64_t iters) {
    for (std::uint64_t i = 0; i < iters; i++) {
        __asm {
            mov eax, 1
            xadd dword ptr unlocked_counter, eax
        };
    }
}

int main() {
    std::uint64_t iters = 1'000'000;
    const auto start1{ std::chrono::steady_clock::now() };
    std::thread t1(worker_locked, iters);
    std::thread t2(worker_locked, iters);
    t1.join();
    t2.join();
    const auto end1{ std::chrono::steady_clock::now() };
    const std::chrono::duration<double> elapsed1{ end1 - start1 };
    std::cout << "Locked xadd counter = " << locked_counter
              << " (expected " << 2 * iters << "). "
              << elapsed1.count() << "s " << "elapsed." << std::endl;
    const auto start2{ std::chrono::steady_clock::now() };
    std::thread t3(worker_unlocked, iters);
    std::thread t4(worker_unlocked, iters);
    t3.join();
    t4.join();
    const auto end2{ std::chrono::steady_clock::now() };
    const std::chrono::duration<double> elapsed2{ end2 - start2 };
    std::cout << "Unlocked xadd counter = " << unlocked_counter
              << " (expected " << 2 * iters << "). "
              << elapsed2.count() << "s " << "elapsed." << std::endl;
}

使用 clang++ -fms-extensions xadd.cpp -o xadd.exe 编译后运行若干次：

std::memory_order_relaxed 的另一作用是约束编译器可能的优化。针对高级语言，std::memory_order_relaxed 还要求原子操作最终的可见性（visibility），即一个线程修改了某变量后，其他线程能够观察到这个修改。

int data = 0;

void thread1() {
    data = 1;
    // do something
    data = 2;
}

void thread2() {
    while (data != 1) { // never fires
        // do something
    }
}

开启 -O2 优化后，clang++ 18.1.3 为 thread1 生成了如下的汇编代码：

mov    DWORD PTR [rip+0x0],0x2
ret
nop    DWORD PTR [rax+rax*1+0x0]

可以看到，thread1 中的两条赋值语句被合并成了一条赋值语句，这就导致了 thread2 永远无法观察到 data == 1。

若将 data 定义为 std::atomic_int，并且在 thread1 中的两条赋值语句后面都加上 std::memory_order_relaxed，上面的问题就能够得到解决。

#include <atomic>

std::atomic_int data = 0;

void thread1() {
    data.store(1, std::memory_order_relaxed);
    // do something
    data.store(2, std::memory_order_relaxed);
}

mov    DWORD PTR [rip+0x0],0x1
mov    DWORD PTR [rip+0x0],0x2
ret
data16 cs nop WORD PTR [rax+rax*1+0x0]

relaxed 内存序存在的问题 §

首先给出下面的一个例子：

std::atomic_bool flag{ false };
int data{ 0 };

void thread1() { // running on CPU#1
    // access to flag, flag now cached and exclusive in CPU#1
    data = 1; // I1
    flag.store(true, std::memory_order_relaxed); // I_2
}

void thread2() { // running on CPU#2
    while (!flag.load(std::memory_order_relaxed)) continue; // I_3
    assert(data == 1); // I_4, may fail
}

即便使用了原子操作，thread1 中的两条 store 指令的先后顺序是没有保证的。假定此时缓存状态如下：

• CPU#1 cache：flag（Exclusive）
• CPU#2 cache：data（Exclusive）

这时，考虑如下执行顺序：

1. CPU#1 执行 $I_{1}$ 。这是一条 store 指令，虽然 CPU#1 目前没有缓存 data，但只要确保其他核心没有缓存 data，就可以直接执行 store。为此，CPU#1 向其他 CPU 核心发送 data 失效消息，并将 1 存入 store buffer，但并不立即写入 cache，只有等到所有 CPU 核心都确认了 data 的失效后，才将 1 写入 cache 中。
2. CPU#2 执行 $I_{3}$ 。发送对 flag 的 load 请求。
3. CPU#1 执行 $I_{2}$ 。由于 flag 已经被 CPU#1 缓存并且处于独占状态，因此 flag 的 store 操作可以直接写入缓存，并由 Exclusive 迁移到 Modified 状态，而无需等待其他 CPU 核心的确认。
4. CPU#1 收到 CPU#2 的 load 请求后，向 CPU#2 发送 flag 的最新值 true，并将状态标记为 Shared。
5. CPU#2 收到 flag 的最新值 true 后，在缓存中添加 flag 的副本，并将状态标记为 Shared。
6. CPU#2 执行 $I_{4}$ 。由于此时 data 已经被缓存，且处于 Exclusive 状态，因此 CPU#2 直接从 cache 中读取 data 的值，此时 data 的值仍然是 0，导致 $I_{4}$ 断言失败。
7. CPU#2 收到 data 的失效消息。data 的 cache 行标记为 Invalid，并向 CPU#1 发送确认消息。
8. CPU#1 收到 CPU#2 的确认消息后，将 1 从 store buffer 写入 cache 中，并将 data 的 cache 行状态置为 Exclusive。
9. $\cdots$

可以看到，thread1 中的两条 store 指令执行效果可见顺序对 thread2 来说是没有保证的。

不同的 CPU 架构对于内存序的保证程度不同，x86 架构下，所有的 load 和 store 操作都是原子的，并且 store 操作符合后文要介绍的顺序一致性（sequential consistency），即在任何线程看来 data 的更新一定发生在 flag 之前，因此在 x86 下永远不会观察到上述情况。而 ARM64 架构则不提供这样的顺序一致性保证，因此上述代码中 thread1 中的两条 store 指令的先后顺序是没有保证的。上面的例子中，CPU#2 所观察到的 flag 和 data 的确只存在旧和新两种状态，也就是说，原子性是满足的。但 CPU#2 观察到的更新顺序却与实际的顺序相反。也就是说，原子性无法保证可见顺序。

为了解决上述问题，现代 CPU 引入了内存屏障（memory barrier）。现代 CPU 提供了一套专门的指令来实现内存屏障的功能。内存屏障指令用于约束 CPU 执行指令的顺序，确保在内存屏障之前的指令执行彻底完成后，才会执行内存屏障之后的指令。C++ 11 引入了 std::atomic_thread_fence，可通过选用不同的内存序，控制编译器使用不同类型的内存屏障指令。 除了专门的内存屏障指令，部分原子指令也能够起到内存屏障的效果。

release 内存序 §

上面的例子错误的根源是 CPU#1 在等待缓存一致性协议的确认过程中，仍可以继续执行后续的 store 指令。由于 CPU 并不知道两次 store 的数据在逻辑上的相关性，因此在其他线程看来，这两次 store 的可见顺序无法得到保证。 为了解决 relaxed 内存序存在的问题，可以使用 release 内存序，用于显示地告知 CPU 可能存在的数据关联。

release 内存序限定 store 的行为，当一个线程执行具有 release 内存序的 store 操作时，CPU 会确保在该 store 操作之前的所有内存操作都已经完成，并且在该 store 操作之后的内存操作不会被重排到该 store 操作之前。使用 std::memory_order_release 后，CPU#1 在执行具有 release 内存序的 $I_{2}$ 时，由于 store buffer 存在尚未完成的操作，而是先标记在此操作之前在 store buffer 中的所有未完成的操作，然后将 flag 的值暂存到 store buffer 中（不做标记）。等到收到其他核心发送的确认消息后，才将 store buffer 中未标记数据写入 cache 中。因此，当 $I_{2}$ 操作的结果可见时， $I_{1}$ 操作的结果也一定可见了。

void thread1() { // running on CPU#1
    data = 1; // I_1
    flag.store(true, std::memory_order_release); // I_2
}

我们仍假定缓存状态如下：

• CPU#1 cache：flag（Exclusive）
• CPU#2 cache：data（Exclusive）

引入 release 内存序后，执行情况如下：

1. CPU#1 执行 $I_{1}$ ，发送 data 读后失效消息，并将 1 暂存到 store buffer。
2. CPU#2 执行 $I_{3}$ ，由于 flag 未被缓存，发送一条消息请求 flag。
3. CPU#1 执行 $I_{2}$ ，由于 store buffer 中存在尚未完成的操作，因此先标记在此操作之前在 store buffer 中的所有未完成的操作，然后将 flag 的新值 true 暂存到 store buffer 中（不做标记）。
4. CPU#1 收到 CPU#2 的 load 请求后，向 CPU#2 发送 flag 的当前值 false，并将状态标记为 Shared。
5. CPU#2 收到 flag 的值 false 后，在缓存中添加 flag 的副本，并将状态标记为 Shared。
6. CPU#2 继续执行 $I_{3}$ 。
7. CPU#2 收到来自 CPU#1 的 data 读后失效消息，将 data 的值通过消息发送给 CPU#1，并将 data 所在缓存行的状态设置为 Invalid。
8. CPU#1 收到 CPU#2 的确认消息后，将暂存在 store buffer 中的 data 新值 1 同步到 cache 中，并标记为 Modified。
9. 由于 CPU#1 的 store buffer 中已标记的暂存数据清空，CPU#1 随后尝试将暂存在 store buffer 中的 flag 新值 true 同步到 cache 中，但由于此时 flag 所在 cache 行处于 Shared 状态，无法更新，因此 CPU#1 发送 flag 失效消息。
10. CPU#2 收到 flag 失效消息，将 flag 所在 cache 行标记为 Invalid，并向 CPU#1 发送确认。
11. CPU#2 继续执行 $I_{3}$ ，但 flag 当前已经失效，因此 CPU#2 发送一条消息请求 flag 的值。
12. CPU#1 收到确认，随机将 cache 中的 flag 更新为 store buffer 中的新值 true，并将其标记为 Modified。
13. CPU#1 收到对 flag 的请求，将 true 通过消息发送给 CPU#2，并将 flag 所在 cache 行标记为 Shared Modified。
14. CPU#2 收到 flag 的值 true，在缓存中添加 flag 的副本，并将状态标记为 Shared。
15. CPU#2 执行 $I_{4}$ ，由于此时 data 处于 Invalid 状态，因此 CPU#2 发送一条读消息请求 data 的值。
16. CPU#1 收到 data 读消息，向 CPU#2 提供 data 的最新值 1，data 所在缓存行变更为 Shared Modified。
17. CPU#2 收到 data 的最新值 1，将其加入缓存，状态置为 Shared。 $I_{4}$ 断言随后通过。

int data;
int flag;

void thread1() { // running on CPU#1
    data = 1;
    std::thread_memory_fence(std::memory_order_release);
    flag = 1;
}

int data;
int counter;

void thread1() { // running on CPU#1
    data = 1;
    std::thread_memory_fence(std::memory_order_release);
    counter++; // alert: not atomic!
}

int data
std::atomic_int counter;

void thread1() { // running on CPU#1
    data = 1;
    std::thread_memory_fence(std::memory_order_release);
    counter.fetch_add(1, std::memory_order_relaxed); // at least relaxed memory order
}

release 内存序的局限性 §

CPU 核心处理失效消息的速度显著慢于其他类型消息的速度。处理失效消息的过程涉及到多个阶段，包括将相关的 cache 行标记为无效、向其他 CPU 核心发送确认消息等，这些操作都需要一定的时间来完成。 假定当前 CPU 核心数据吞吐量非常大，此时 cache 非常繁忙，而恰好 CPU 收到了一条失效消息。若 CPU 必须立即处理这条失效消息，将会造成其他 CPU 核心产生更多的 stalls，导致性能下降。现代 CPU 采取的做法是引入消息队列来缓存收到的消息。当前 CPU 核心收到失效消息后，并不立即处理，而是将其加入专门存放失效消息的队列（invalidate queue，后文译作失效队列） 中，并且立即向其他核心发送确认消息，等到 cache 空闲时再处理失效消息，失效队列的存在也会影响到可见顺序。

release 内存序确保了写者线程中 release 操作及其之前的操作的可见性，但在引入失效队列后，读者线程若仍使用 std::memory_order_relaxed 读取 flag，随后执行的 data 仍有可能读取到旧值。

std::atomic_bool flag{ false };
int data{ 0 };

void thread1() { // running on CPU#1
    data = 1; // I_1
    flag.store(true, std::memory_order_release); // I_2
}

void thread2() { // running on CPU#2
    while (!flag.load(std::memory_order_relaxed)) continue; // I_3
    assert(data == 1); // I_4, may fail
}

假定此时缓存状态如下：

• CPU#1：flag（Exclusive）、data（Shared）
• CPU#2：data（Shared）

1. CPU#1 执行 $I_{1}$ ，由于 data 已经被 CPU#1 缓存并且处于 Shared 状态，因此 CPU#1 向其他核心发送 data 的失效消息，并将 1 存入 store buffer，但并不立即写入 cache，只有等到所有 CPU 核心都确认了 data 的失效后，才将 1 写入 cache 中。
2. CPU#1 执行 $I_{2}$ ，由于 store buffer 中存在尚未完成的操作，因此先标记在此操作之前在 store buffer 中的所有未完成的操作，然后将 flag 的新值 true 暂存到 store buffer 中（不做标记）。等到收到其他核心发送的确认消息后，才将 store buffer 中未标记数据写入 cache 中。
3. CPU#2 收到 CPU#1 发送的 data 失效消息，将失效消息添加到失效队列，并立即向 CPU#1 发送确认消息。
4. CPU#2 执行 $I_{3}$ ，发送对 flag 的 load 请求。
5. CPU#1 收到 CPU#1 发送的确认消息后，将 store buffer 中的 data 新值 1 同步到 cache 中，并标记为 Modified Exclusive。Cache 中的 flag 随即更新为 store buffer 中的新值 true，并将其标记为 Modified。
6. CPU#1 收到 CPU#2 的 load 请求后，向 CPU#2 发送 flag 的当前值 true，并将状态标记为 Modified Shared。
7. CPU#2 收到 flag 的值 true 后，在缓存中添加 flag 的副本，并将状态标记为 Shared。
8. CPU#2 执行 $I_{4}$ ，由于此时 data 仍处于 Shared 状态，因此 CPU#2 直接从 cache 中读取 data 的值，此时 data 的值仍然是 0，导致 $I_{4}$ 断言失败。
9. CPU#2 处理失效队列中的 data 失效消息，将 data 的 cache 行标记为 Invalid，但已经无法阻止 $I_{4}$ 读取到旧值了。

可以看到，即便写者线程中的 release 操作及其之前的操作的可见性得到了保证，但读者线程仍有可能观察到 release 操作之前的操作的旧值。这是由于失效队列的存在导致的。为了解决这个问题，读者线程需要告知 CPU flag 和 data 之间的依赖关系。本质上，就是要求 CPU#2 在读取 data 之前，先清空失效队列中的消息，确保 data 的 cache 行的状态是最新的，这就引出了与 release 内存序配套的 acquire 内存序。

void thread2() { // running on CPU#2
    while (!flag.load(std::memory_order_acquire)) continue; // I_3
    assert(data == 1); // I_4, guaranteed to pass
}

假定此时缓存状态如下：

• CPU#1：flag（Exclusive）、data（Shared）
• CPU#2：data（Shared）

我们再来审视一下上述代码的执行情况：

1. CPU#1 执行 $I_{1}$ ，由于 data 已经被 CPU#1 缓存并且处于 Shared 状态，因此 CPU#1 向其他核心发送 data 的失效消息，并将 1 存入 store buffer，但并不立即写入 cache，只有等到所有 CPU 核心都确认了 data 的失效后，才将 1 写入 cache 中。
2. CPU#1 执行 $I_{2}$ ，由于 store buffer 中存在尚未完成的操作，因此先标记在此操作之前在 store buffer 中的所有未完成的操作，然后将 flag 的新值 true 暂存到 store buffer 中（不做标记）。等到收到其他核心发送的确认消息后，才将 store buffer 中未标记数据写入 cache 中。
3. CPU#2 收到 CPU#1 发送的 data 失效消息，将失效消息添加到失效队列，并立即向 CPU#1 发送确认消息。
4. CPU#2 执行 $I_{3}$ ，发送对 flag 的 load 请求。
5. CPU#1 收到 CPU#1 发送的确认消息后，将 store buffer 中的 data 新值 1 同步到 cache 中，并标记为 Modified Exclusive。Cache 中的 flag 随即更新为 store buffer 中的新值 true，并将其标记为 Modified。
6. CPU#1 收到 CPU#2 的 load 请求后，向 CPU#2 发送 flag 的当前值 true，并将状态标记为 Modified Shared。
7. CPU#2 收到 flag 的值 true 后，在缓存中添加 flag 的副本，并将状态标记为 Shared。
8. CPU#2 等待失效队列中的消息被处理完毕，CPU#2 处理失效队列中的 data 失效消息，将 data 的 cache 行标记为 Invalid。
9. CPU#2 继续执行 $I_{4}$ ，由于此时 data 已经被标记为 Invalid，因此 CPU#2 发送一条消息请求 data 的值。
10. CPU#1 收到 data 读消息，向 CPU#2 提供 data 的最新值 1，状态变更为 Modified Shared。
11. CPU#2 收到 data 的最新值 1，将其加入缓存，状态置为 Shared。 $I_{4}$ 断言随后通过。

int data{ 0 };
bool flag{ false };

void thread1() { // running on CPU#1
    data = 1; // I_1
    std::thread_memory_fence(std::memory_order_release);
    flag = true; // I_2
}

void thread2() { // running on CPU#2
    while (!flag) continue; // I_3
    std::thread_memory_fence(std::memory_order_acquire);
    assert(data == 1); // I_4, guaranteed to pass
}

被废弃的 consume 内存序 §

除了 acquire 内存序，C++ 11 还引入了 consume 内存序，consume 内存序的语义与 acquire 内存序类似，但它的约束范围更小，仅仅对相关的数据在保证原子性的基础上限制了编译器的指令重排，换句话说，在硬件层面，编译器生成的代码仍是一条普通的 relaxed 原子指令。Consume 主要是尝试在 acquire 内存序的基础上减少现在进一步提升性能。然而，在之前介绍 acquire 内存序的小节中，我们实际上已经注意到采用 relaxed 内存序读取以 release 内存序写入的变量时，读者线程仍有可能观察到 release 内存序之前的操作的旧值。因此，这个内存序的实际定位，在 C++ 26 标准中，consume 内存序被废弃了。

acquire-release 内存序 §

Acquire-release 内存序是 acquire 内存序和 release 内存序的组合，适用于那些既需要保证前续操作的可见性，又需要保证后续操作的可见性的场景。对于 acquire-release 内存序的原子指令来说，其 load 部分具有 acquire 内存序的语义，而 store 部分具有 release 内存序的语义，因此 acquire-release 内存序的原子指令在执行时会同时满足 acquire 内存序和 release 内存序的约束。

CPU 除了提供基础的 load 和 store 指令，还提供了一些同时具备 load 和 store 功能的指令，这些指令被称为读-改-写（read-modify-write）指令。之前提到的 x86 xadd 指令就是一例，除了修改目标操作数，源操作数中还加载了目标操作数修改前的原值。

C++ 使用 fetch_add 和 fetch_sub 封装了读-改-写指令，并且允许开发者为其指定内存序。对于 fetch_add 和 fetch_sub 来说，若需要使用目标操作数修改前的原值，就需要用到 acquire-release 内存序，以同时满足先前操作和后续操作的可见性要求。

std::atomic_int counter{ 0 };
constexpr int threshold{ 100 };

void producer() {
    int old_value = counter.fetch_add(1, std::memory_order_acq_rel);
    if (old_value == threshold - 1) {
        // do something
    }
}

void consumer() {
    int old_value = counter.fetch_sub(1, std::memory_order_acq_rel);
    if (old_value == 1) {
        // do something
    }
}

sequentially-consistent 内存序 §

有了 acquire 内存序和 release 内存序，看起来我们已经能够满足大部分的内存序要求了，那么为什么 C++ 11 还要引入 sequentially-consistent 内存序呢？sequentially-consistent 内存序（后文译作顺序一致性）是 C++ 11 中内存序要求最高的内存序，除了满足 acquire 内存序和 release 内存序的约束外，还要求所有线程观察到的修改顺序是一致的。我们仍然举一个例子来说明为什么 acquire 内存序和 release 内存序无法解决所有的内存序问题：

std::atomic_int x{ 0 }, y{ 0 };

void thread1() {
    x.store(1, std::memory_order_release); // I_1
    int r1 = y.load(std::memory_order_acquire); // I_2
}

void thread2() {
    y.store(1, std::memory_order_release); // I_3
    int r2 = x.load(std::memory_order_acquire); // I_4
}

假定此时缓存状态如下：

• CPU#1：x（Shared）、y（Shared）
• CPU#2：x（Shared）、y（Shared）

考虑如下执行顺序：

1. CPU#1 执行 $I_{1}$ ，由于 x 已经被 CPU#1 缓存并且处于 Shared 状态，因此 CPU#1 向其他核心发送 x 的失效消息，并将 1 存入 store buffer，但并不立即写入 cache，只有等到所有 CPU 核心都确认了 x 的失效后，才将 1 写入 cache 中。
2. CPU#1 执行 $I_{2}$ ，由于 y 已经被 CPU#1 缓存并且处于 Shared 状态，因此 CPU#1 直接从 cache 中读取 y 的值，此时 y 的值仍然是 0，因此 $I_{2}$ 读取到的值为 0。
3. CPU#2 执行 $I_{3}$ ，由于 y 已经被 CPU#2 缓存并且处于 Shared 状态，因此 CPU#2 向其他核心发送 y 的失效消息，并将 1 存入 store buffer，但并不立即写入 cache，只有等到所有 CPU 核心都确认了 y 的失效后，才将 1 写入 cache 中。
4. CPU#2 执行 $I_{4}$ ，由于 x 已经被 CPU#2 缓存并且处于 Shared 状态，因此 CPU#2 直接从 cache 中读取 x 的值，此时 x 的值仍然是 0，因此 $I_{4}$ 读取到的值为 0。
5. CPU#1 收到 CPU#2 发送的 y 失效消息，将 y 的 cache 行标记为 Invalid，并向 CPU#2 发送确认消息。
6. CPU#2 收到 CPU#1 发送的确认消息后，将 y 的新值 1 同步到 cache 中，并标记为 Modified。
7. CPU#2 收到 CPU#1 发送的 x 失效消息，将 x 的 cache 行标记为 Invalid，并向 CPU#1 发送确认消息。
8. CPU#1 收到 CPU#2 发送的确认消息后，将 x 的新值 1 同步到 cache 中，并标记为 Modified。

上面的执行顺序导致一个这样的结果：r1 == 0 && r2 == 0。也就是说，两个线程都没有观察到对方的更新。从顺序一致性的角度来看：

• r1 == 0 意味着 $I_2 \prec I_3$ 。 ⁴
• r2 == 0 意味着 $I_4 \prec I_1$ 。
• release 内存序要求 $I_1 \prec I_2$ 和 $I_3 \prec I_4$ 。

因此，以上的执行顺序导致了一个矛盾的全局顺序： $I_1 \prec I_2 \prec I_3 \prec I_4 \prec I_1$ 。那么，为什么这样的事情会发生呢？我们再回过头看指令的执行过程，在 CPU#1 执行 $I_{1}$ 时，仅仅是简单地在 store buffer 中暂存了 x 的新值 1，并没有立即将其写入 cache 中，因此这条指令实际上对于 CPU#2 而言并未开始执行，CPU#2 所感知到的执行顺序实际上是 $I_2 \prec I_1$ 。究其本质，实际上是 release 内存序允许指令执行部分地延后。

我们再来分析一下引入顺序一致性后的执行情况：

std::atomic_int x{ 0 }, y{ 0 };

void thread1() {
    x.store(1, std::memory_order_seq_cst); // I_1
    int r1 = y.load(std::memory_order_seq_cst); // I_2
}

void thread2() {
    y.store(1, std::memory_order_seq_cst); // I_3
    int r2 = x.load(std::memory_order_seq_cst); // I_4
}

仍然假定此时缓存状态如下：

• CPU#1：x（Shared）、y（Shared）
• CPU#2：x（Shared）、y（Shared）

1. CPU#1 执行 $I_{1}$ ，由于 x 已经被 CPU#1 缓存并且处于 Shared 状态，因此 CPU#1 向其他核心发送 x 的失效消息，并将 1 存入 store buffer，但并不立即写入 cache，只有等到所有 CPU 核心都确认了 x 的失效后，才将 1 写入 cache 中。
2. CPU#1 执行 $I_{2}$ ，由于该指令要求求顺序一致性，因此 CPU#1 需要确保 $I_{1}$ 的执行彻底完成后，才会执行 $I_{2}$ 。因此，CPU#1 等待 store buffer 中的 x 新值 1 被写入 cache 中，并且等待所有 CPU 核心都确认了 x 的失效后，才会执行 $I_{2}$ 。由于此时 y 的值仍然是 0，因此 $I_{2}$ 读取到的值为 0。
3. CPU#2 执行 $I_{3}$ ，由于 y 已经被 CPU#2 缓存并且处于 Shared 状态，因此 CPU#2 向其他核心发送 y 的失效消息，并将 1 存入 store buffer，但并不立即写入 cache，只有等到所有 CPU 核心都确认了 y 的失效后，才将 1 写入 cache 中。
4. CPU#2 执行 $I_{4}$ ，由于该指令要求求顺序一致性，因此 CPU#2 需要确保 $I_{3}$ 的执行彻底完成后，才会执行 $I_{4}$ 。因此，CPU#2 等待 store buffer 中的 y 新值 1 被写入 cache 中，并且等待所有 CPU 核心都确认了 y 的失效后，才会执行 $I_{4}$ 。由于此时 x 的值仍然是 0，因此 $I_{4}$ 读取到的值为 0。
5. CPU#2 收到 CPU#1 发送的 x 失效消息，将 x 的 cache 行标记为 Invalid，并向 CPU#1 发送确认消息。
6. CPU#1 收到 CPU#2 发送的确认消息后，将 x 的新值 1 同步到 cache 中，并标记为 Modified。 $I_2$ 随后执行，读取到的 y 值为 0。
7. CPU#1 收到 CPU#2 发送的 y 失效消息，将 y 的 cache 行标记为 Invalid，并向 CPU#2 发送确认消息。
8. CPU#2 收到 CPU#1 发送的确认消息后，将 y 的新值 1 同步到 cache 中，并标记为 Modified。 $I_4$ 随后执行，由于 x 已经被标记为 Invalid，因此 CPU#2 发送一条消息请求 x 的值。
9. CPU#1 收到 x 读消息，向 CPU#2 提供 x 的最新值 1，状态变更为 Modified Shared。
10. CPU#2 收到 x 的最新值 1，将其加入缓存，状态置为 Shared。 $I_4$ 随后恢复执行，读取到的 x 值为 1。

执行结束后，r1 == 0 && r2 == 1。可以推导出全局顺序 $I_1 \prec I_2 \prec I_3 \prec I_4$ ，将这个顺序与 CPU#1 和 CPU#2 所观察到的顺序进行比对，可以确认全局顺序与每个 CPU 核心所观察到的顺序是一致的。

int x{ 0 }, y{ 0 };

void thread1() {
    x = 1; // I_1
    std::thread_memory_fence(std::memory_order_seq_cst);
    int r1 = y; // I_2
    std::thread_memory_fence(std::memory_order_seq_cst);
}

void thread2() {
    y = 1; // I_3
    std::thread_memory_fence(std::memory_order_seq_cst);
    int r2 = x; // I_4
    std::thread_memory_fence(std::memory_order_seq_cst);
}