C11 atomics：同一变量上的relaxed load与release store如何交互？

我最近在写一个大量用到原子操作的多线程程序，结果发现在ARM平台上这些原子操作慢得离谱——编译器居然插了好多内存栅栏，有时候连循环里都插！所以我想通过调整内存序来去掉那些没必要的栅栏，提升性能。

不过现在碰到个拿不准的情况：如果我在同一个原子变量上，用memory_order_relaxed的load去读取用memory_order_release存的值，这样做安全吗？就拿简单的参数读取场景来说，核心就是原子变量的release存储和relaxed加载的交互问题。

别担心，先给你划个核心结论：如果你的场景只是保证这个原子变量本身的值能被正确读到（也就是不会读到“半更新”的脏值），那用relaxed load去读release store的原子变量是完全安全的。

为啥这么说？首先，不管是什么内存序，原子操作本身都保证了变量的操作是原子性的——也就是说，不会出现读取到变量被更新到一半的中间值的情况，这是原子操作的基础特性，和内存序无关。

那release和relaxed的区别在哪？主要是内存可见性的范围：

• 用memory_order_release去store一个原子变量，主要是为了保证：在这个store之前的所有非原子操作、以及其他原子操作的结果，对之后用memory_order_acquire去load这个原子变量的线程是可见的。简单说就是“把之前的操作都同步到其他线程”。
• 而memory_order_relaxed的load，只保证自己的原子性，不参与任何同步——也就是说，它不会管这个原子变量的store操作之前的其他操作有没有被同步过来，它只保证读到的这个原子变量的值是某个完整的store结果（要么是旧值，要么是release store之后的新值，不会是中间值）。

那回到你的场景，如果你的参数读取逻辑里，只关心这个原子变量本身的最新值，不需要依赖这个变量store之前的其他操作的可见性，那用relaxed load完全没问题，而且不会触发编译器插入多余的内存栅栏，正好解决你ARM平台上的性能问题。

但如果你的场景里，这个原子变量的更新还伴随着其他变量的更新——比如你先更新了一个普通变量，再用release store去更新原子变量，然后希望其他线程读到原子变量的新值时，也能读到那个普通变量的新值——那这时候你就不能用relaxed load了，必须用acquire load，不然其他线程可能会读到原子变量的新值，但普通变量还是旧值，这就出问题了。

总结一下：

• 仅原子变量本身的读写正确性：relaxed load + release store 完全安全
• 需要同步其他变量的可见性：必须用acquire load + release store，不能用relaxed

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