存储是释放操作，加载是两者的获取操作。我知道memory_order_seq_cst 旨在为所有操作强加一个额外的总排序，但我无法构建一个示例，如果所有memory_order_seq_cst 都被memory_order_acq_rel 替换，情况并非如此。
我是否遗漏了什么，或者差异只是文档效果，即如果一个人不打算使用更宽松的模型，应该使用memory_order_seq_cst，而在约束宽松模型时使用memory_order_acq_rel？
【问题讨论】：
标签： c++ c++11 memory-model stdatomic
http://en.cppreference.com/w/cpp/atomic/memory_order 有一个很好的例子at the bottom，它只适用于memory_order_seq_cst。本质上memory_order_acq_rel 提供相对于原子变量的读写顺序，而memory_order_seq_cst 提供全局读写顺序。也就是说，顺序一致的操作在所有线程中以相同的顺序可见。
这个例子归结为：
bool x= false;
bool y= false;
int z= 0;
a() { x= true; }
b() { y= true; }
c() { while (!x); if (y) z++; }
d() { while (!y); if (x) z++; }
// kick off a, b, c, d, join all threads
assert(z!=0);
z 上的操作由两个原子变量保护，而不是一个，因此您不能使用获取-释放语义来强制 z 始终递增。
【讨论】：
z 也会是 2。
c()可以感知a()中的x=true;发生在y=true;之前b()同时d()可以感知到y=true;发生在之前x=true;（由于缺少“全局排序”。）特别是c()可以同时感知x==true和y==falsed()可以感知y==true和x==false。所以z 可能不会增加c() 或d()。使用 seq_cst，如果 c() 感知到 x=true; 发生在 y=true; 之前，那么 d() 也是如此。
int z=0，而不是bool z=0
std::memory_order_acq_rel 的实际 RMW 操作。在原子读取-修改-写入中，加载和存储是绑定在一起的，因为它们是原子的。我不确定acq_rel 是否会与seq_cst 不同，例如.fetch_add 或.compare_exchange_weak
在 x86 等 ISA 上，原子映射到障碍，实际机器模型包括存储缓冲区：
seq_cst 存储需要刷新存储缓冲区，因此该线程稍后的读取会延迟到存储全局可见之后。
acquire 或 release 不 必须刷新存储缓冲区。正常的 x86 加载和存储本质上具有 acq 和 rel 语义。 （seq_cst 加上一个带有存储转发的存储缓冲区。）
但是 x86 原子 RMW 操作总是被提升为 seq_cst，因为 x86 asm lock 前缀是一个完整的内存屏障。其他 ISA 可以在 asm 中轻松或 acq_rel RMW，商店方面能够与以后的商店进行有限的重新订购。 （但不是以使 RMW 看起来非原子的方式：For purposes of ordering, is atomic read-modify-write one operation or two?）
https://preshing.com/20120515/memory-reordering-caught-in-the-act 是 seq_cst 存储和普通发布存储之间区别的一个有启发性的示例。（实际上是 mov + mfence 与 x86 asm 中的普通 mov。实际上，xchg 是在大多数 x86 CPU 上进行 seq_cst 存储的更有效方式，但 GCC 确实使用 mov+mfence)
有趣的事实：AArch64 的 LDAR 获取-加载指令实际上是一个顺序-获取，与 STLR 有特殊的交互。直到 ARMv8.3 LDAPR 才能 arm64 执行普通的获取操作，这些操作可以使用早期版本和 seq_cst 存储 (STLR) 重新排序。 （seq_cst 加载仍然使用 LDAR，因为它们 need that interaction with STLR 来恢复顺序一致性；seq_cst 和 release 存储都使用 STLR。
使用 STLR / LDAR，您可以获得顺序一致性，但只需要在下一个 LDAR 之前排空存储缓冲区，而不是在每个 seq_cst 存储之后在其他操作之前立即排空。我认为真正的 AArch64 硬件确实以这种方式实现它，而不是在提交 STLR 之前简单地耗尽存储缓冲区。
使用 LDAR / STLR 将 rel 或 acq_rel 增强为 seq_cst 并不需要很昂贵，除非您 seq_cst 存储一些内容，然后 seq_cst 加载其他内容。那么它和 x86 一样糟糕。
其他一些 ISA（如 PowerPC）有更多的壁垒选择，可以比 mo_seq_cst 更便宜地强化到 mo_rel 或 mo_acq_rel，但它们的 seq_cst 不能像 AArch64 一样便宜； seq-cst 商店需要一个完整的屏障。
因此，AArch64 是 seq_cst 存储在现场耗尽存储缓冲区的规则的一个例外，无论是使用特殊指令还是之后的屏障指令。 ARMv8 是在 C++11 / Java / 等之后设计的 并非巧合。基本上将 seq_cst 作为无锁原子操作的默认值，因此使它们高效很重要。在 CPU 架构师花了几年时间考虑提供屏障指令或只是获取/释放与宽松的加载/存储指令的替代方案之后。
【讨论】：
lock 前缀的全内存屏障特性由 Intel 和 AMD 在其 x86 ISA 手册中仔细记录。 (Does lock xchg have the same behavior as mfence?)。对于未来的 x86 CPU，它绝对有保证；编译器还能如何制作安全的面向未来的 asm？这就是我的意思是编译器必须加强所有 RMW 操作到 asm 中的 seq_cst，在 RMW 执行它的操作之前耗尽存储缓冲区。
xdiv（如果 FPU 决定支持 RMW，则为 xcos），CPU 不会尝试获取已加载的值并提前在内存中准备好计算，因此加快代价高昂的 RMW？
machine_clears.memory_ordering 性能计数器：Why flush the pipeline for Memory Order Violation caused by other logical processors?）
尝试仅使用获取/释放语义构建 Dekkers 或 Petersons 算法。
这行不通，因为获取/释放语义不提供 [StoreLoad] 栅栏。
在 Dekkers 算法的情况下：
flag[self]=1 <-- STORE
while(true){
if(flag[other]==0) { <--- LOAD
break;
}
flag[self]=0;
while(turn==other);
flag[self]=1
}
如果没有 [StoreLoad] 栅栏，商店可能会跳到负载前面，然后算法就会中断。 2个线程同时看到另一个锁是空闲的，设置自己的锁并继续。现在您在临界区中有 2 个线程。
【讨论】：
仍然使用memory_order 中的定义和示例。但是将 memory_order_seq_cst 替换为 store 中的 memory_order_release 和 load 中的 memory_order_acquire。
Release-Acquire ordering 保证了在一个线程中的 store 之前发生的所有事情在执行加载的线程中成为可见的副作用。但在我们的示例中，在 thread0 和 thread1 中 store 之前什么都没有发生。
x.store(true, std::memory_order_release); // thread0
y.store(true, std::memory_order_release); // thread1
另外，没有memory_order_seq_cst，thread2和thread3的顺序是不能保证的。你可以想象它们变成：
if (y.load(std::memory_order_acquire)) { ++z; } // thread2, load y first
while (!x.load(std::memory_order_acquire)); // and then, load x
if (x.load(std::memory_order_acquire)) { ++z; } // thread3, load x first
while (!y.load(std::memory_order_acquire)); // and then, load y
所以，如果 thread2 和 thread3 在 thread0 和 thread1 之前执行，这意味着 x 和 y 都保持为 false，因此 ++z 永远不会被触及，z 保持 0 并且断言触发。
但是，如果 memory_order_seq_cst 进入图片，它会为所有被标记的原子操作建立一个单一的总修改顺序。因此，在 thread2 中，x.load 然后 y.load；在 thread3 中，y.load 然后 x.load 是确定的事情。
【讨论】：