c++ - 在 WinAPI、POSIX 或 API-OS 的其他扩展中是否存在 C++11 的所有级别的内存屏障？

Question

在 WinAPI、POSIX 或 API-OS 的其他扩展中是否存在 C++11 中的所有级别的内存屏障 std::memory_order ，它定义了编译器和处理器流水线对操作重新排序时的优化限制？

enum memory_order {
    memory_order_relaxed,
    memory_order_consume,
    memory_order_acquire,
    memory_order_release,
    memory_order_acq_rel,
    memory_order_seq_cst
};

补充:存在 WinAPI 中的示例 MemoryBarrier() ，但它仅等同于 std::atomic_thread_fence( std::memory_order_seq_cst );。因为 Windows 主要在 x86 系统上运行，其中普通加载具有获取语义，普通存储具有释放语义:http://www.stdthread.co.uk/forum/index.php?topic=72.0

但是，即使缓存 L3 (LLC) 和 x86 的管道根据这些语义取消了对 load() 和 store() 的重新排序优化 - std::memory_order_acquire/std::memory_order_release 还需要禁用编译器优化。

它存在于 WinAPI :

The _ReadBarrier, _WriteBarrier, and _ReadWriteBarrier compilerintrinsics prevent only compiler re-ordering. To prevent the CPU fromre-ordering read and write operations, use the MemoryBarrier macro.

有GCC built-in functions for memory model aware atomic operations :

__ATOMIC_RELAXED No barriers or synchronization.

__ATOMIC_CONSUME Data dependency only for both barrier and synchronization with another thread.

__ATOMIC_ACQUIRE Barrier to hoisting of code and synchronizes with release (or stronger) semantic stores from another thread.

__ATOMIC_RELEASE Barrier to sinking of code and synchronizes with acquire (or stronger) semantic loads from another thread.

__ATOMIC_ACQ_REL Full barrier in both directions and synchronizes with acquire loads and release stores in another thread.

__ATOMIC_SEQ_CST Full barrier in both directions and synchronizes with acquire loads and release stores in all threads.

我可以使用 POSIX 禁用此编译器优化吗？

Answer 1

通常不是 API 标准的一部分，但在大多数编译器中以一种或另一种形式作为内在函数提供。

例如，Visual Studio 编译器有 _ReadBarrier , _ReadWriteBarrier和 _WriteBarrier . (我只链接了一个，因为有从该页面到其余页面的链接。不，这些不是您列出的所有级别 - 但它们是 x86 具有的所有级别......std::memory_order 中的列表涵盖了还有很多其他架构。[显然 memory_order_relaxed 是“无”]。

GCC 具有不同类型的内置功能，描述了 here ，旨在提供原子更新，而不是专门的障碍。

但是，一般来说，我会把它留给编译器/操作系统来处理原子的事情——使用 std::atomic<>和类似的。