c++ - memory_order_seq_cst 和 memory_order_release 的可能排序

Question

引用以下代码

auto x = std::atomic<std::uint64_t>{0};
auto y = std::atomic<std::uint64_t>{0};

// thread 1
x.store(1, std::memory_order_release);
auto one = y.load(std::memory_order_seq_cst);

// thread 2
y.fetch_add(1, std::memory_order_seq_cst);
auto two = x.load(std::memory_order_seq_cst);

这里有没有可能one和two都是0？

---

(我似乎遇到了一个错误，如果 one 和 two 在上面的代码运行后都可以保持 0 的值，则可以解释这个错误。以及规则排序太复杂了，我无法弄清楚上面可能的排序。)

Answer 1

是的，两个负载都有可能得到 0。

在线程 1 中，y.load 可以“传递”x.store(mo_release)，因为它们不是 seq_cst。 ISO C++ 保证必须存在的 seq_cst 操作的全局总顺序仅包括 seq_cst 操作。

(就普通 CPU 的硬件/CPU 架构而言，负载可以在发布存储离开存储缓冲区之前从连贯缓存中获取值。在这种情况下，我发现根据我怎么知道它是为 x86(或 to generic release and acquire operations)编译的，然后应用 asm 内存排序规则。应用这个推理假设正常的 C++->asm mappings 是安全的，并且总是至少与 C++ 内存模型一样强大。如果你可以通过这种方式找到合法的重新排序，你不需要费力地通过 C++ 形式主义。但如果你不这样做，那当然不能证明它在 C++ 抽象机中是安全的。)

无论如何，要意识到的关键点是 seq_cst 操作不像 atomic_thread_fence(mo_seq_cst) - 单个 seq_cst 操作只有以它们与其他 seq_cst 操作交互的方式恢复/保持顺序一致性，而不是与普通的获取/释放/acq_rel。 (同样，获取和释放栅栏是更强的双向障碍，不同于获取和释放操作 Jeff Preshing explains。)

---

实现这一点的重新排序

这是唯一可能的重新排序；其他可能性只是两个线程的程序顺序的交错。让商店最后“发生”(变得可见)导致 0, 0 结果。

我将 one 和 two 重命名为 r1 和 r2 (每个线程中的本地“寄存器”)，避免写类似 one == 0 的东西。

// x=0 nominally executes in T1, but doesn't have to drain the store buffer before later loads
auto r1 = y.load(std::memory_order_seq_cst);   // T1b             r1 = 0 (y)
         y.fetch_add(1, std::memory_order_seq_cst);      // T2a   y = 1 becomes globally visible
         auto r2 = x.load(std::memory_order_seq_cst);    // T2b   r2 = 0 (x)
x.store(1, std::memory_order_release);         // T1a             x = 0 eventually becomes globally visible

这实际上可能发生在 x86 上，但有趣的是不会发生在 AArch64 上。 x86 可以在没有额外障碍的情况下进行 release-store(只是一个普通的 store)，seq_cst 加载的编译方式与 plain acquire 相同，只是一个普通的加载。

在 AArch64 上，release 和 seq_cst 存储使用 STLR。 seq_cst 加载使用 LDAR，它与 STLR 有特殊的交互，在最后一个 STLR 从存储缓冲区中耗尽之前不允许读取缓存。所以 ARMv8 上的 release-store/seq_cst load 和 seq_cst store/seq_cst load 是一样的。 (ARMv8.3 添加了 LDAPR，通过让获取加载以不同方式编译来允许真正的获取/释放；参见 this Q&A。)

然而，它也可能发生在许多使用单独屏障指令的 ISA 上，例如 ARM32:发布存储通常会使用屏障完成，然后是普通存储，以防止重新排序较早加载/商店，但不会停止重新订购。如果 seq_cst 加载避免在自身之前需要一个完整的屏障(这是正常情况)，那么存储可以在加载后重新排序。

例如，ARMv7 上的发布存储是 dmb ish； str，一个seq_cst负载是ldr； dmb ish，所以你有 str/ldr，它们之间没有障碍。

在 PowerPC 上，因为 seq_cst 负载是 hwsync； ld；厘米;公元前; isync，所以在加载之前有一个完整的屏障。 (我认为 HeavyWeight Sync 是防止 IRIW 重新排序的一部分，用于阻止同一物理内核上的 SMT 线程之间的存储转发，只有当它们实际上变得全局可见时才能看到来自其他内核的存储。)