移除内存栅栏后C++ memory_order_relaxed代码仍正常运行，原因何在？

首先明确核心结论：使用std::memory_order_relaxed时，理论上确实存在z.load() == 0的可能，但你的测试未触发该情况，和M1 Mac的ARMv8架构特性、测试样本量、编译器行为有关，与未察觉的release sequence无关。

1. 原示例中release/acquire的保障逻辑 #

原示例的release/acquire栅栏（或原子操作的release/acquire语义）建立了明确的线程同步关系：

• 线程1中对x和y的release写入，会确保所有在该release操作之前的内存操作，对执行acquire读取的线程可见。
• 线程2中对x和y的acquire读取，会同步到线程1的release写入，因此线程2必然能看到x=1和y=1，最终z会被设为1，断言不会触发。

2. relaxed版本的理论风险 #

当改用std::memory_order_relaxed时，原子操作之间没有任何同步约束，线程间的内存可见性完全依赖硬件隐式行为：

• 线程1的x.store(1, relaxed)和y.store(1, relaxed)，硬件理论上允许这两个store操作的顺序在其他线程中被观测到乱序（尽管ARMv8对store-store重排有约束，但跨线程的可见性仍可能存在延迟）。
• 线程2的x.load(relaxed)和y.load(relaxed)，可能出现只看到x=1但y=0，或只看到y=1但x=0的情况，此时z会被赋值为0，触发断言。

3. 测试未触发断言的原因 #

（1）ARMv8架构的内存模型特性

M1基于ARMv8架构，其内存模型属于多拷贝原子（Multi-Copy Atomic, MCA），且对内存操作重排有严格约束：

• 同一线程内的store操作不会被重排到之前的store操作之后（store-store不重排）。
• 同一线程内的load操作不会被重排到之前的load操作之前（load-load不重排）。
• 虽然store-load可能重排，但你的测试场景中，线程1的两个store、线程2的两个load都是连续操作，硬件层面的可见性延迟很难在十万次测试中体现，导致x和y的写入几乎总是同时被线程2观测到。

（2）测试样本量不足

这种数据竞争导致的错误是概率性的，十万次测试在ARM架构下远远不够。要触发该情况，可能需要百万甚至千万次测试，或者在线程1的两个store之间、线程2的两个load之间插入短时间空循环，人为增加乱序可见的概率。

（3）编译器优化的影响

g++在ARM平台下对std::memory_order_relaxed的编译，可能生成了偏“紧凑”的代码：比如将线程1的两个store合并为连续内存操作，或对线程2的load操作进行顺序优化，进一步降低了乱序出现的概率。

4. 关于release sequence的排除 #

release sequence是基于release语义操作的链式传递，而你的代码中所有原子操作都是relaxed，不存在任何release操作，因此不可能形成release sequence，这一点可直接排除。

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