1. volatile 修饰符#

volatile 关键字的核心作用是告知编译器，被修饰变量的值随时可能在编译器无法察觉的情况下发生改变。例如通过硬件中断服务例程(ISR)、内存映射的硬件设备(MMIO)或信号处理函数。因此，它对编译器施加了两个关键约束：

• 抑制编译器优化：确保每次访问 volatile 变量时，都直接从其内存地址读取或写入，而不是使用寄存器中缓存的旧值。
• 防止编译器重排：编译器不会将对 volatile 变量的访问指令与其他 volatile 变量的访问指令进行重排序。

一个经典的例子：（常见于嵌入式）

1
// done 变量可能被硬件、中断服务程序或其他线程修改
2
// volatile 确保编译器每次循环都会重新从内存加载 done 的值，而不是在寄存器中不断读取
3
volatile bool done = false;
4
while (!done) {
5
    // 等待 done 变为 true
6
}

volatile 的局限性： 关键在于，volatile 仅对编译器有效，它无法限制 CPU 的乱序执行(Out-of-Order Execution)。现代 CPU 为了最大化提升性能，可能会对内存操作进行重排序。因此，volatile 不能提供跨线程的内存可见性和顺序性的同步保证，也不能保证操作的原子性。在多线程编程中，单独使用 volatile 来保证共享变量的可见性和顺序性是错误且危险的。

2. atomic = 原子操作 + 内存顺序: 现代并发编程的基石#

为了解决 volatile 的局限性，C++11 标准引入了原子操作(std::atomic)和内存顺序(std::memory_order)。

• 原子性 (Atomicity)：保证一个操作（如读、写、修改）在执行过程中不会被其他线程中断。它要么完全执行，要么完全不执行，不存在中间状态。这是通过特殊的 CPU 指令（如 x86 的 LOCK 前缀）实现的。
• 内存顺序 (Memory Ordering)：定义了原子操作如何影响其他内存操作的可见性顺序，即构造一个事件的“发生在…之前”(happens-before) 的关系，从而限制编译器和 CPU 的乱序行为。 std::atomic 有两个功能：原子 & 内存序 原则：

大多数变量无需是原子的。只有当一个变量可能被多个线程同时访问，且至少有一个访问是写操作时，才必须将其声明为原子类型。这能帮助编译器和 CPU 精确地知道哪些内存访问需要特别保护，从而在保证并发安全的同时，最大化对其他代码的优化。

3. 内存屏障(Memory Barrier)：显式控制乱序#

编译器优化、CPU、缓存 都有可能导致乱序执行

内存屏障是用于在代码中创建同步点的指令，它可以阻止编译器和 CPU 跨越屏障进行指令重排。

1
// 告诉编译器，内存中的所有内容都可能已改变
2
// 禁止编译器将屏障前的内存读写指令重排到屏障后，反之亦然
3
asm volatile("" ::: "memory");

1
// GCC/Clang 内置函数，生成一个全功能的内存屏障
2
__sync_synchronize();

4. 内存序 std::memory_order (重点)#

内存顺序是 C++ 并发编程中最精细也最复杂的工具，它允许程序员根据具体场景选择不同强度的同步保证，以实现性能和正确性之间的最佳平衡。

• memory_order_relaxed：宽松序。 这是最弱的内存序，仅保证操作的原子性，不提供任何跨线程的顺序保证。没有额外的内存同步语义，允许指令自由重排（与架构有关）。
• memory_order_acquire：获取序。 通常用在读操作上。它建立了一个“获取屏障”，禁止该操作之后的所有内存操作被重排到该操作之前。它必须与一个 release 操作配对，以观察其写入的数据。
• memory_order_release：释放序。 通常用在写操作上。它建立了一个“释放屏障”，禁止该操作之前的所有内存操作被重排到该操作之后。所有在 release 操作之前发生的写操作，对于之后执行相应 acquire 操作的线程都是可见的。
• memory_order_acq_rel：获取-释放序。 同时具备 acquire 和 release 的特性，通常用于“读-修改-写”类型的操作。它既能“获取”其他线程 release 的数据，又能向其他线程 release 自己的写入。
• memory_order_consume：消费序。这是一个与 acquire 类似的较弱版本，仅对存在依赖关系的操作施加顺序限制。由于其复杂性和实现难度，目前主流编译器通常会将其提升为 memory_order_acquire 对待，因此在实践中较少使用。
• memory_order_seq_cst：顺序一致性。 这是最强的内存序，也是默认的内存序。它不仅提供 acquire 和 release 的保证，还确保所有线程看到的 seq_cst 操作都遵循一个单一的、全局的总顺序。 这意味着不会出现“凭空加载”(out-of-thin-air reads) 等现象，但性能开销也最大。

显然，memory_order是有性能开销的：

1
std::atomic<int> count = 0;
2
count.fetch_add(1, std::memory_order_relaxed); // (x86)lock add ✅
3
// 类似于（但其实是一个不可分的 lock add 原子指令操作）
4
// r0 = load // relaxed
5
// add r0, r0, #1
6
// store r0  // relaxed
7
count.fetch_add(1, std::memory_order_acq_rel); // (x86)lock add ✅
8
// r0 = load // acquire
9
// add r0, r0, #1
10
// store r0  // release
11

12
// 等价于 .fetch_add(1, std::memory_order_seq_cst); ✅
13
count += 1; // count++; ++count;
14

15
// 等价于 count.store(count.load() + 1); // 是3条可分的指令，不保证原子性，线程不安全 ❌
16
count = count + 1;
17

18
// Q: 现在我知道了count = count + 1;线程不安全，但是我怎么处理自定义运算呢？
19
// A: CAS
20
// P.S 如果 count 是会被其他线程读取的，需改为release的CAS，反之可以直接全部使用relaxed
21
int old_count = count.load(std::memory_order_relaxed);
22
int new_count;
23
do {
24
    new_count = f(old_count) // 自定义运算(不依赖于其他共享数据)
25
} while (!count.compare_exchange_weak(old_count, new_count, std::memory_order_release, std::memory_order_relaxed));

5. 示例代码#

这个 release-acquire 模型是并发编程中最常用、最高效的同步范式之一。

1
#include <atomic>
2
#include <thread>
3
std::atomic<bool> done {false};
4
void worker() {
5
    // 生产者线程完成一些工作后...
6
    // 使用 memory_order_release，确保在 done = true 之前的所有写操作
7
    // 对于消费线程都是可见的。
8
    done.store(true, std::memory_order_release);
9
}
10
void waiter() {
11
    // 消费者线程等待工作完成
12
    // 使用 memory_order_acquire，确保在读取到 done == true 后
13
    // 能看到生产者在 release 之前的所有写操作。
14
    while (!done.load(std::memory_order_acquire)) {
15
        // 等待
16
    }
17
    // 在此之后，可以安全地访问生产者写入的数据
18
}

1
// 自旋锁
2
struct SpinMutex {
3
    std::atomic<bool> flag{false};
4
    bool try_lock() {
5
        bool expected = false;
6
        if (flag.compare_exchange_strong(expected, true, std::memory_order_acquire, std::memory_order_relaxed))
7
            // load barrier
8
            return true;
9
        return false;
10
    }
11
    void lock() {
12
        bool expected = false;
13
        while (!flag.compare_exchange_weak(expected, true, std::memory_order_acquire, std::memory_order_relaxed))
14
            expected = false; // 因为STD的CAS中 weakCAS失败后会把传入的引用(expected)修改，只能手动赋值为false重置。。
15
        // load barrier
16
    }
17
    void unlock() {
18
        // data change and then unlock.
19
        // store barrier
20
        flag.store(false, std::memory_order_release);
21
    }
22
    // 使用 futex 等待队列 优化自旋
23
    void lock_futex() {
24
        bool expected;
25
#if __cpp_lib_atomic_wait
26
        int retries = 1000;
27
        do {
28
            expected = false;
29
            if (flag.compare_exchange_weak(expected, true, std::memory_order_acquire, std::memory_order_relaxed))
30
                // load barrier
31
                return;
32
        } while (--retries);
33
#endif
34
        do {
35
#if __cpp_lib_atomic_wait
36
            // fast-user-space mutex = futex (linux) SYS_futex
37
            flag.wait(true, std::memory_order_relaxed); // wait until not true
38
#endif
39
            expected = false;
40
        } while (!flag.compare_exchange_weak(expected, true, std::memory_order_acquire, std::memory_order_relaxed));
41
        // load barrier
42
    }
43
    void unlock_futex() {
44
        // data change and then unlock
45
        // store barrier
46
        flag.store(false, std::memory_order_release);
47
#if __cpp_lib_atomic_wait
48
        flag.notify_one();
49
#endif
50
    }
51
};

6. 不同架构的内存模型的区别：#

x86 架构：强内存模型(TSO, Total Store Order 完全存储定序)，除 StoreLoad 外，基本不允许其他重排。 ARM 架构：弱内存模型，允许 LoadLoad, LoadStore, StoreStore等多种重排。

• 对 memory_order_relaxed 来说：
  • x86因架构本身内存限制已很强，跟seq_cst只有禁止StoreLoad重排、保证全局顺序一致性的区别
  • ARM则会允许各种重排，内存序relax只保证该原子操作本身是原子的，别的不管。
• 对 memory_order_seq_cst ：
  • ARM 使用指令集 stlr (=dmb ish + str + dmb ish), ldar

P.S. 没有 ARM 架构的PC完全可以考虑手机下载 Termux，然后电脑ssh上去编译cpp代码来观察其内存序行为(pkg install clang)

• Q: 性能动机: 为什么x86“独爱”StoreLoad重排，只允许了它的存在
  • A: 核心在于写操作Store的延迟远高于读操作Load。当一个CPU核心要写入一个内存地址时，它必须首先通过缓存一致性协议（如MESI）获得该地址所在缓存行(Cache Line)的独占所有权(Exclusive)。这个过程可能非常耗时：对非独占的缓存行，此核心必须发送“读取并无效化”(Read For Ownership)的请求，等待其他核心将缓存行失效并把最新数据发送过来；甚至cache miss导致要从主存中加载，延迟更高。导致整个执行流水线都必须停顿！
  • Store-Load重排的实际流程：不等待直接将“STORE x, 数据”这个写操作放入存储缓冲区，然后立即继续执行下一条指令。执行Load指令。此时，内存控制器并行地在后台缓慢地处理存储缓冲区中的写请求，以及Load指令的读请求，实现对高延迟的写操作“异步化”。

总结#

• volatile：用于与内存映射的硬件交互或在信号处理程序中使用（如：嵌入式），不用于线程间同步。
• 编译器屏障：仅阻止编译器重排，无法阻止硬件乱序。
• 硬件屏障：功能强大但开销高，通常通过原子操作间接使用。
• 原子操作 + 内存顺序：是现代 C++ 中进行多线程编程的正确且唯一可靠的方式。它通过提供精确的原子性和内存顺序保证，从根本上解决了数据竞争和未定义行为的问题。
• 认识到架构差异: 为编写可移植的正确代码，必须依据C++标准，而非某种特定架构的行为。所以x86开发者（强内存模型）也需要学习完整的内存序知识并在CI中添加ARM架构测试（