为什么这个“std::atomic_thread_fence”起作用

首先我想谈一下我对此的一些理解，如有错误请指正。

1. a MFENCE在x86中可以保证全屏障

2. 顺序一致性可防止 STORE-STORE、STORE-LOAD、LOAD-STORE 和 LOAD-LOAD 重新排序

   这是根据维基百科 https://en.wikipedia.org/wiki/Memory_ordering.

3. std::memory_order_seq_cst不保证防止 STORE-LOAD 重新排序。

   这是根据亚历克斯的回答 https://stackoverflow.com/questions/39053600/does-standard-c11-guarantee-that-memory-order-seq-cst-prevents-storeload-reord?rq=1、“负载可能会与早期存储一起重新排序到不同位置”（对于 x86）并且 mfence 不会始终被添加。

   无论是std::memory_order_seq_cst表示顺序一致性？根据第2/3点，我认为这似乎不正确。std::memory_order_seq_cst仅当以下情况时才表示顺序一致性

   1. 至少一个明确的MFENCE添加到任一LOAD or STORE
   2. LOAD（无栅栏）和 LOCK XCHG
   3. LOCK XADD ( 0 ) 和 STORE （无栅栏）

   否则仍有可能重新订购。

   根据@LWimsey 的评论，我在这里犯了一个错误，如果两者都LOAD and STORE are memory_order_seq_cst，没有重新排序。 Alex 可能指出使用非原子或非 SC 的情况。

4. std::atomic_thread_fence(memory_order_seq_cst)总是产生一个完整的屏障

   这是根据亚历克斯的回答 https://stackoverflow.com/questions/25478029/does-atomic-thread-fencememory-order-seq-cst-have-the-semantics-of-a-full-memo。所以我可以随时更换asm volatile("mfence" ::: "memory") with std::atomic_thread_fence(memory_order_seq_cst)

   这对我来说很奇怪，因为memory_order_seq_cst原子函数和栅栏函数之间的用法似乎有很大不同。

现在我在MSVC 2015的标准库的头文件中找到这段代码，它实现了std::atomic_thread_fence

inline void _Atomic_thread_fence(memory_order _Order)
    {   /* force memory visibility and inhibit compiler reordering */
 #if defined(_M_ARM) || defined(_M_ARM64)
    if (_Order != memory_order_relaxed)
        {
        _Memory_barrier();
        }

 #else
    _Compiler_barrier();
    if (_Order == memory_order_seq_cst)
        {   /* force visibility */
        static _Uint4_t _Guard;
        _Atomic_exchange_4(&_Guard, 0, memory_order_seq_cst);
        _Compiler_barrier();
        }
 #endif
    }

所以我的主要问题是如何_Atomic_exchange_4(&_Guard, 0, memory_order_seq_cst);打造全面屏障MFENCE，或者实际上做了什么来启用类似的等效机制MFENCE，因为一个_Compiler_barrier()显然这里对于完整的内存屏障来说是不够的，或者这个语句的工作原理有点类似于第 3 点？

所以我的主要问题是如何_Atomic_exchange_4(&_Guard, 0, memory_order_seq_cst);创建一个完整的屏障 MFENCE

This compiles to an xchg instruction with a memory destination. This is a full memory barrier (draining the store buffer) exactly¹ like mfence.

在此之前和之后存在编译器障碍，也可以防止围绕它的编译时重新排序。因此，阻止了任一方向上的所有重新排序（原子和非原子 C++ 对象上的操作），使其足够强大，可以执行 ISO C++ 的所有操作atomic_thread_fence(mo_seq_cst)承诺。

对于弱于 seq_cst 的指令，只需要编译器屏障。 x86 的硬件内存排序模型是程序顺序 + 具有存储转发的存储缓冲区。这足够强大了acq_rel编译器不会发出任何特殊的 asm 指令，只是阻止编译时重新排序。https://preshing.com/20120930/weak-vs-strong-memory-models/ https://preshing.com/20120930/weak-vs-strong-memory-models/

脚注1：完全足以满足 std::atomic 的目的。来自 WC 内存的弱有序 MOVNTDQA 加载可能不会严格排序lockMFENCE 的编辑说明。

• x86 上哪个写屏障更好：lock+addl 或 xchgl？ https://stackoverflow.com/questions/4232660/which-is-a-better-write-barrier-on-x86-lockaddl-or-xchgl/52910647#52910647
• lock xchg 与 mfence 具有相同的行为吗？ https://stackoverflow.com/questions/40409297/does-lock-xchg-have-the-same-behavior-as-mfence- 与 std::atomic 目的相同，但对于使用 WC 内存区域的设备驱动程序可能存在一些细微的差异。以及性能差异。尤其在 Skylake 上mfence阻止 OoO exec 类似lfence https://stackoverflow.com/questions/50494658/are-loads-and-stores-the-only-instructions-that-gets-reordered
• 为什么 LOCK 在 x86 上是完全屏障？ https://stackoverflow.com/questions/60332591/why-is-lock-a-full-barrier-on-x86

x86 上的原子读-修改-写 (RMW) 操作只能通过lock前缀，或xchg有记忆 https://www.felixcloutier.com/x86/xchg即使机器代码中没有锁定前缀，情况也是如此。带锁前缀的指令（或带有 mem 的 xchg）始终是完整的内存屏障。

使用类似的指令lock add dword [esp], 0作为替代品mfence是一项众所周知的技术。 （并且在某些 CPU 上性能更好。）这个 MSVC 代码是相同的想法，但它不是对堆栈指针指向的任何内容执行无操作，而是执行xchg在虚拟变量上。实际上它在哪里并不重要，但是仅由当前核心访问并且在缓存中已经很热的缓存线是性能的最佳选择。

Using a static所有核心都将争夺访问权限的共享变量是最糟糕的选择；这段代码太糟糕了！无需与其他核心相同的高速缓存行交互来控制该核心对其自己的 L1d 高速缓存的操作顺序。这完全是疯了。 MSVC 显然仍然在其实现中使用这个可怕的代码std::atomic_thread_fence()，即使对于 x86-64，其中mfence保证可用。 (Godbolt 与 MSVC 19.14 https://godbolt.org/#z:OYLghAFBqd5QCxAYwPYBMCmBRdBLAF1QCcAaPECAM1QDsCBlZAQwBtMQBGAFlICsupVs1qhkAUgBMAISnTSAZ0ztkBPHUqZa6AMKpWAVwC2tLgFZSW9ABk8tTADljAI0zEQADlIAHVAsLqtHqGJuY%2BfgF0tvZORq7uXkoqanQMBMzEBMHGppwWSZiqgWkZBNGOLm6eiumZ2aF5NaXlsfGeAJSKqAbEyBwA5FIAzHbIhlgA1OJDOsxERngSQ9jiAAwAgmvrAG6oeOgTzhnEeG4Q7VMA7LIbE3cTCgToICBzqAvIAPoECMSYzOhPlQtH0II9niAjJgjCQAJ6fEhYYifJQAR0%2ByEe7WmN02lwAIlstrt9g8iH8UcgwU8Xm8PtMdHYCNNsFNJAA2bYZC7ia5be4TLnEKZDfETTiSIY4okE/qdVggfpmfqkUz9VYq1CKnRyOQPbq9TBsoacFUERUa9qdBD/JGUToAaxAQ24ADoAJwednu7hmTjey4SrwK/rcFVqjWkLX9FUKECrUjm9Vy0hwWBINBGbx4dhkCgQTPZ3MoVifewAd0%2B7N4VBzBDccYgzgtKucdgysMVptImah9AA8rRWJ3k6QsEYRMB2C2x3g/kVtpg46PMAAPQoGetdlVM5Qz1h4ZzEDt6LDbxMnIzbzo0ehMNgcHj8QTCUQoXUyISHuOQTqobwpLQy4ALT9pIsbKIUgGaNo9S5JY2gtJU7icOE/iAXBgi%2BOhgRIXEVSoQURSpLUWT6DkghEYBJSZHhbSEaRmEMc0dgVPhKGdAoBp9Fw8qKsqqoztGq7VhMRgKNsyCCpw7qujwEwQAA6gAkg42AXBAuCECQxqoRMehZjmbi6RcOoyHIZotp0EAZu8RZuOQlCFkZ7iLMgMmobWrD1sQjbNqOba0B2569loBCDsOM7jpO06jvg85qIuy6RmuG5bv03a7iGkYHkeJ4YAM3YEJe16kLejAsNOT4CEMQiTu%2B5mfrlP7nFGAGBCB/ZDBBySBDBujkQ0CE2KxrQEWhkRBIN8HYZNdHjVRxSMdNlGQcRtA0WUo3IZRy0hPBjwsTEO2cJx3GPnxSrhkJiqrl6wGiW54qyasckKVp5K6aQ%2Bl2S5xpDKZH7SJZyZWqQTpDJIrpmKs7JmJIlzcHkPBDOyQiKmGgmjtGsbxomVmpjAiAoL9uaOQWpNVMA7q1V5Pl%2BTOgXBRlKqhQOQ4jpG0WiLFXNzlBeBJTOqXIJuhU7vQe6jrlx7ELCp7ixeeBXizN50BVD5cLwAiSHVb4SI18jNfAf7tXQnXdYoa3QRAVhMcN80oRNGErahs2AY7q29SRpT24tPu0dt7G7b7rtNIHx3B6dXQ9Dx0chgJEaard92icAyBSbJQzvfgn3DHpBn2cKwySIDhsg5a1q2lUrUQ1DMNwwjSN%2BtwqPo6G13Y4quMJkmlft%2BBWORjj%2BOg50i6%2BX13BAA)

如果你正在做 seq_cststore，你的选择是mov+mfence（海湾合作委员会这样做）或做商店and障碍与单一xchg（clang 和 MSVC 这样做，所以代码生成很好，没有共享虚拟变量）。

这个问题的大部分早期部分（陈述“事实”）似乎都是错误的，并且包含一些误解或被误导的事情，甚至没有错。

std::memory_order_seq_cst不保证防止 STORE-LOAD 重新排序。

C++ 使用完全不同的模型来保证顺序，其中获取加载从发布存储中看到的值与其“同步”，并且 C++ 源代码中的后续操作保证可以看到发布存储之前代码中的所有存储。

它还保证总订单为allseq_cst 操作甚至可以跨不同的对象。 （较弱的顺序允许线程在其自己的存储变得全局可见之前重新加载，即存储转发。这就是为什么只有 seq_cst 必须耗尽存储缓冲区。它们还允许 IRIW 重新排序。其他线程是否总是以相同的顺序看到对不同线程中不同位置的两个原子写入？ https://stackoverflow.com/questions/27807118/will-two-atomic-writes-to-different-locations-in-different-threads-always-be-see/50679223#50679223)

StoreLoad 重新排序等概念基于以下模型：

• 所有核心间通信都是通过将存储提交到缓存一致的共享内存
• 重新排序发生在一个核心内部对缓存的访问之间。例如通过存储缓冲区延迟存储可见性，直到稍后加载（如 x86 允许）。 （除非核心可以通过商店转发尽早看到自己的商店。）

就该模型而言，seq_cst 确实需要在 seq_cst 存储和稍后的 seq_cst 加载之间的某个时刻耗尽存储缓冲区。实现这一目标的有效方法是设置全面的屏障afterseq_cst 存储。 （而不是在每次 seq_cst 加载之前。便宜的加载比便宜的存储更重要。）

在像 AArch64 这样的 ISA 上，有加载获取和存储释放指令，它们实际上具有顺序释放语义，这与 x86 加载/存储“仅”常规释放不同。 （因此 AArch64 seq_cst 不需要单独的屏障；微体系结构可以延迟耗尽存储缓冲区，除非/直到执行加载获取，同时仍然有存储释放未提交到 L1d 缓存。）其他 ISA 通常需要完整的屏障在 seq_cst 存储之后耗尽存储缓冲区的指令。

当然，即使是 AArch64 也需要完整的屏障指令seq_cst fence，不同于seq_cst加载或存储手术.

std::atomic_thread_fence(memory_order_seq_cst)总是产生一个完整的屏障

实际上是的。

所以我可以随时更换asm volatile("mfence" ::: "memory") with std::atomic_thread_fence(memory_order_seq_cst)

实际上是的，但理论上，实现可能允许对非原子操作进行一些重新排序std::atomic_thread_fence并且仍然符合标准。Always这是一个非常强烈的词。

ISO C++ 仅在以下情况下保证任何内容std::atomic涉及加载或存储操作。 GNU C++ 可以让你推出自己的原子操作asm("" ::: "memory")编译器障碍 (acq_rel) 和asm("mfence" ::: "memory")全面壁垒。将其转换为 ISO C++ signal_fence 和 thread_fence 将留下一个具有数据争用 UB 的“可移植”ISO C++ 程序，因此无法保证任何内容。

（尽管请注意，滚动你自己的原子应该使用至少volatile https://stackoverflow.com/questions/4557979/when-to-use-volatile-with-multi-threading/58535118#58535118，而不仅仅是障碍，以确保编译器不会发明多个加载，即使您避免了将加载提升到循环之外的明显问题。谁害怕一个糟糕的优化编译器？ https://lwn.net/Articles/793253/).

永远记住，实现所做的事情必须是at least与 ISO C++ 所保证的一样强大。这往往最终会变得更强大。