原子RMW操作在无Release/Acquire内存顺序场景下的缓存一致性验证问询

嗨，你的问题问到了原子操作里一个很容易混淆的细节，我来帮你理清楚：

首先直接给结论：你的理解只在x86这类强内存模型的CPU上成立，在ARM、PowerPC这类弱内存模型的CPU上并不一定正确。下面拆开来解释：

先搞懂两个核心概念 #

• RMW操作的原子性≠跨变量可见性
  原子读-修改-写（RMW）操作比如atomic_fetch_sub，确实会保证读、修改、写这三步是一个不可分割的原子序列——执行过程中其他CPU没法插进来修改这个变量。为了做到这一点，CPU执行RMW时必须先拿到该缓存行的独占权限，这会强制同步这个变量的当前全局最新状态。但要注意：这里的“最新”是指当前已经同步到全局内存的修改，不保证一定能看到某个特定线程的未同步写入。

• relaxed内存顺序的本质
  你用的memory_order_relaxed只保证操作本身是原子的，完全不限制硬件的内存重排（虽然你加了atomic_signal_fence阻止编译器重排，但硬件层面的重排它管不了）。比如在弱内存模型CPU上，线程0里的两个relaxed store是可能被硬件重排顺序的——atoBool=1的写入可能先同步到全局，而atoInt=42的写入还停留在线程0的本地缓存里。

结合你的代码场景分析 #

• 在x86等强内存模型CPU上：硬件不允许store-store重排，线程0里atoInt=42的写入一定会先于atoBool=1同步到全局。所以当线程1循环等到atoBool=1时，atoInt=42的修改已经全局可见了——不管是relaxed load还是RMW操作，都会拿到42，你的两个断言都会通过。

• 在ARM等弱内存模型CPU上：硬件允许store-store重排，线程0可能先把atoBool=1同步出去，而atoInt=42还没同步。这时候线程1看到atoBool=1后：

  • relaxed loadatoInt会拿到旧值0，这符合你对relaxed加载的预期；
  • 执行RMW操作atomic_fetch_sub时，CPU会同步atoInt的全局状态——如果此时线程0的atoInt=42还没同步到全局，那RMW拿到的就是0，你的第二个断言会直接失败。

怎么保证RMW一定拿到42？ #

如果想让线程1看到atoBool=1时，一定能看到atoInt=42，不管什么硬件，你需要用release-acquire内存顺序建立happens-before关系：

• 线程0里把atoBool的存储改成atomic_store_explicit(&atoBool,1,memory_order_release)；
• 线程1里把atoBool的加载改成atomic_load_explicit(&atoBool,memory_order_acquire)；

这样一来，线程0中release操作之前的所有写入（包括atoInt=42），对线程1中acquire操作之后的所有操作都是可见的，彻底解决了跨变量的可见性问题。

备注：内容来源于stack exchange，提问作者Petr Skocik