`std::atomic` 的 6 种 memory_order 到底该怎么选——从 store buffer 到 ARM `dmb` 指令，一张决策树解决 90% 的场景

你以为flag.store(true)只是一个赋值？

在 ARM Cortex-A76 上，当你写下flag.store(true)而没有指定任何 memory_order 时——也就是说编译器替你选了默认的memory_order_seq_cst——这行看似无辜的 C++ 代码会被翻译成一条STR指令加上一条DMB ISH指令，后者的作用是强制当前核心排空整个 Store Buffer、等待所有尚未提交到缓存一致性域的写操作对集群内其他核心变得可见，而这个"排空并等待"的过程在中等负载下需要消耗 40 到 80 个时钟周期——这意味着你每次不假思索地用默认语义写一个原子 store，都在为一种你可能根本不需要的"全局一致序"保证支付一笔你看不见的硬件税。

但如果你确切地知道这里只需要一个 release 语义——也就是说你只需要保证这次 store 之前的所有写操作在这次 store 对其他核心可见的时候都已经可见——那么编译器只需要产出一条STLR（Store-Release）指令，这是 ARMv8 专门为 release 语义设计的指令，它不需要排空整个 Store Buffer，只需要确保当前 store 不会被重排到它之前的 store 前面，代价通常在个位数的时钟周期。

40-80 个周期 vs 个位数周期。

问题在于，绝大多数 C++ 程序员从来没有意识到这笔性能差距的存在，原因很简单：在 x86 上——也就是你日常开发和调试的平台上——mem