c++ - 为什么具有顺序一致性的std::atomic存储区使用XCHG？

Question

为什么 std::atomic 's store :

std::atomic<int> my_atomic;
my_atomic.store(1, std::memory_order_seq_cst);

当请求具有顺序一致性的商店时，执行 xchg 吗？

从技术上讲，具有读/写内存屏障的普通存储是否足够？相当于:

_ReadWriteBarrier(); // Or `asm volatile("" ::: "memory");` for gcc/clang
my_atomic.store(1, std::memory_order_acquire);

我在明确地谈论x86和x86_64。商店具有隐式获取栅栏的地方。

Answer 1

mov -store + mfence 和 xchg 都是在x86上实现顺序一致性存储的有效方法。 带有内存的lock上的隐式xchg前缀使其成为完整的内存屏障，就像x86上的所有原子RMW操作一样。
(x86的内存排序规则实质上使全屏障效应成为任何原子RMW的唯一选择:它同时是负载和存储，并以全局顺序固定在一起。原子性要求负载和存储不只是通过将存储区排队到存储缓冲区中来分开，因此必须将其排空，并且负载侧的负载-负载排序要求它不必重新排序。)
普通的mov是不够的；它仅具有发布语义，而不具有顺序发布。 (与AArch64的stlr指令不同，后者执行顺序发布存储，该顺序发布存储无法与以后的ldar顺序获取加载重新排序。此选择显然是由C++ 11将seq_cst作为默认内存顺序来驱动的。但是，AArch64的常规存储是弱得多；放松不释放。)
请参阅Jeff Preshing's article on acquire / release semantics，并请注意，常规发行版存储(如mov或xchg以外的任何非锁定x86内存目标指令)允许对以后的操作进行重新排序，包括获取负载(如mov或任何x86内存源操作数)。例如如果发布商店正在释放锁，则可以在关键部分内部出现以后的内容。

在不同CPU上上的mfence和xchg之间存在性能差异，并且可能在热缓存与冷缓存以及竞争与非竞争的情况下。和/或在同一个线程中背靠背执行多个操作的吞吐量，而不是一个线程，并且允许周围的代码与原子操作重叠执行。
请参阅https://shipilev.net/blog/2014/on-the-fence-with-dependencies，以了解mfence与lock addl $0, -8(%rsp)与(%rsp)的实际基准，将其作为一个完整的障碍(如果您还没有商店的话)。
在Intel Skylake硬件上，mfence阻止无序执行独立的ALU指令，但xchg不会。 (See my test asm + results in the bottom of this SO answer)。英特尔的手册并不要求它具有如此强大的功能。只有lfence可以做到这一点。但是，作为实现细节，在Skylake上乱序执行周围的代码非常昂贵。
我尚未测试其他CPU，所以可能是a microcode fix for erratum SKL079 的结果，WC存储器中的SKL079 MOVNTDQA可能通过了早期的MFENCE指令。勘误表的存在基本上证明了SKL在MFENCE之后能够执行指令。如果他们通过使MFENCE在微代码中更强来解决问题，我将不会感到惊讶，这是一种钝器手段，可显着增加对周围代码的影响。
我只测试了L1d缓存中缓存行很热的单线程情况。 (当内存变冷或在另一个内核上处于Modified状态时，则不需要。)xchg必须加载先前的值，从而对内存中的旧值创建“false”依赖项。但是mfence强制CPU等待，直到先前的存储提交到L1d，这也需要高速缓存行到达(并处于M状态)。因此，它们在这方面可能大致相等，但英特尔的mfence迫使所有内容等待，而不仅仅是加载。
AMD的优化手册为原子seq-cst存储建议使用xchg。我以为Intel建议使用较老的gcc使用的mov + mfence，但是英特尔的编译器在这里也使用xchg 。
当我进行测试时，在同一位置重复进行单线程循环时，在Skyt上xchg的吞吐量要比mov + mfence更好。有关详细信息，请参见Agner Fog's microarch guide and instruction tables，但他不会在锁定操作上花费很多时间。
有关C++ 11 seq-cst my_atomic = 4;的信息，请参见gcc/clang/ICC/MSVC output on the Godbolt compiler explorer。 gcc在SSE2可用时使用mov + mfence。 (使用-m32 -mno-sse2也可以让gcc也使用xchg)。其他3个编译器都喜欢使用默认调整的xchg或znver1(Ryzen)或skylake。
Linux内核将xchg用作 __smp_store_mb()。
更新:最新的GCC(如GCC10)已更改为像其他编译器一样将xchg用于seq-cst存储，即使mfence的SSE2可用。

另一个有趣的问题是如何编译atomic_thread_fence(mo_seq_cst); 。显而易见的选项是mfence，但是lock or dword [rsp], 0是另一个有效的选项(当MFENCE不可用时，由gcc -m32使用)。堆栈的底部通常在M状态的缓存中已经很热。缺点是如果本地存储在本地，则会引入延迟。 (如果只是返回地址，则返回地址预测通常非常好，因此延迟ret的读取能力并不成问题。)因此，在某些情况下lock or dword [rsp-4], 0值得考虑。 (gcc did consider it，但是将其还原，因为它会使valgrind感到不高兴。这是在知道即使mfence可用时它也可能比mfence更好的方法。)
当前，所有编译器都将mfence用作独立的屏障(如果可用)。这些在C++ 11代码中很少见，但是对于真正的多线程代码(在无锁通信的线程内正在进行实际工作)真正最有效的方法，还需要进行更多的研究。
，但是有多个消息来源建议使用lock add作为堆栈的屏障，而不是mfence ，因此，即使SSE2可用，Linux内核最近也将其用于x86上的smp_mb()实现。
有关更多讨论，请参见https://groups.google.com/d/msg/fa.linux.kernel/hNOoIZc6I9E/pVO3hB5ABAAJ，其中包括有关HSW/BDW的一些勘误表，其中涉及通过早期movntdqa ed指令从WC内存加载lock的问题。 (在Skylake的对面，那里是mfence而不是lock ed指令是一个问题。但是与SKL不同，微代码没有修复。这就是为什么Linux仍将mfence用作其mb()驱动程序的原因，以防万一任何使用NT负载的情况从视频RAM或其他东西复制回来，但要等到可见较早的存储后才能进行读取。)

In Linux 4.14，smp_mb()使用mb()。如果可用，则使用mfence，否则使用lock addl $0, 0(%esp)。__smp_store_mb(存储+内存屏障)使用xchg(并且在以后的内核中不会更改)。

In Linux 4.15，smb_mb()使用lock; addl $0,-4(%esp)或%rsp，而不是mb()。 (即使在64位中，内核也不使用红色区域，因此-4可能有助于避免本地var的额外延迟)。
驱动程序使用mb()来订购对MMIO区域的访问，但是smp_mb()在为单处理器系统编译时变成无操作。更改mb()更具风险，因为它更难测试(影响驱动程序)，并且CPU具有与锁vs.mfence有关的勘误表。但是无论如何，mb()使用mfence(如果可用)，否则使用lock addl $0, -4(%esp)。唯一的变化是-4。

In Linux 4.16，除了删除#if defined(CONFIG_X86_PPRO_FENCE)以外，没有其他更改，该my_atomic.store(1, std::memory_order_acquire);为比现代硬件实现的x86-TSO模型更弱的内存模型定义了东西。

x86 & x86_64. Where a store has an implicit acquire fence

我希望你的意思是释放。 ojit_code无法编译，因为只写原子操作不能是获取操作。另请参见 Jeff Preshing's article on acquire/release semantics。

Or asm volatile("" ::: "memory");

不，那只是编译器的障碍。它会阻止所有 compile-time reordering跨过它，但不会阻止 runtime StoreLoad reordering，即直到稍后才对商店进行缓冲，并且在以后的加载之后才以全局顺序出现。 (StoreLoad是x86允许的唯一一种重新排序运行时。)
无论如何，在这里表达您想要的另一种方式是:

my_atomic.store(1, std::memory_order_release);        // mov
// with no operations in between, there's nothing for the release-store to be delayed past
std::atomic_thread_fence(std::memory_order_seq_cst);  // mfence

使用发布围栏还不够强大(它和发布存储都可能会延迟到以后的加载之后，这与说发布围栏不会阻止以后的加载尽早发生是一回事)。但是，通过发布获取隔离区可以解决问题，避免以后的加载尽早发生，并且本身无法通过发布存储重新排序。
相关: Jeff Preshing's article on fences being different from release operations。
但是请注意，根据C++ 11规则seq-cst是特殊的:保证仅seq-cst操作具有单个全局/总顺序，所有线程都同意此顺序。因此，在C++抽象机上，即使它们在x86上，用较弱的阶数+栅栏来模拟它们通常也不完全相同。 (在x86上，所有存储都具有一个所有内核都同意的单一总顺序。另请参见 Globally Invisible load instructions:负载可以从存储缓冲区中获取其数据，因此我们不能真正说出负载+存储的总顺序。)