为何atomic_thread_fence需原子操作才能正常工作？兼与smp屏障对比

C++内存模型：根据指定的顺序，建立非原子访问和宽松原子访问的内存同步顺序，无需关联原子操作。但请注意，如下文所述，建立同步至少需要一个原子操作。

问题在于：为何必须要求原子操作？

我原本认为atomic_thread_fence的作用是刷新Load-Store队列，和Linux内核中的smp_rmb/smp_wmb功能相同。因此如下代码看似可行：

int i = 0, j = 0;

// cpu0:
i = 1;
atomic_thread_fence(memory_order_release);
j = 2;

// cpu1
int k = j;
atomic_thread_fence(memory_order_acquire);
if (k == 2) {
    assert(i == 1);
}

但根据C++内存顺序规则，这段代码并不合法。因此我的问题是：atomic_thread_fence与smp_rmb/smp_wmb之间的差异是什么？

作为对比，如下代码是完全合法的：

int i = 0, j = 0;

// cpu0:
i = 1;
smp_wmb();
j = 2;

// cpu1
int k = j;
smp_rmb();
if (k == 2) {
    assert(i == 1);
}

核心差异解析 #

1. C++内存模型的同步依赖原子操作
   C++标准中，atomic_thread_fence本身无法单独建立跨线程的同步关系，它必须配合原子操作的"释放-获取"语义才能形成有效的同步链。原因在于：

• 非原子变量的读写没有全局统一的可见性保证，编译器或CPU可能对非原子操作进行重排（比如把j=2提前到atomic_thread_fence之前执行），或者通过Store缓冲区合并导致内存顺序混乱。
• 第一段代码中，j是普通int，CPU0的j=2和CPU1的k=j都是非原子操作，C++标准不认可这两个操作之间存在可靠的可见性关系，因此fence无法在它们之间建立同步，assert(i == 1)可能触发。

2. 内核内存屏障是硬件级的直接约束
   Linux内核的smp_wmb/smp_rmb是针对SMP系统的硬件级内存屏障，作用是直接约束CPU的内存访问顺序：

• smp_wmb()确保屏障前的写操作（i=1）一定在屏障后的写操作（j=2）之前被其他CPU可见；
• smp_rmb()确保读j的操作一定在读i之前完成。
• 内核代码有额外的同步约定（比如不会出现无保护的并发读写普通变量），因此这种直接用于普通变量的写法是合法的。

3. 本质区别

• atomic_thread_fence是语言层面的抽象，核心是为了符合C++内存模型的"无数据竞争"要求，必须依附原子操作才能完成跨线程同步。
• smp_*mb是硬件层面的指令，直接控制CPU的内存访问行为，依赖内核代码自身的同步规范来保证安全性。

内容的提问来源于stack exchange，提问作者user2256177