在WinAPI、POSIX或API-OS等价物的其他扩展中，是否存在来自C++11的所有级别的内存屏障

Is there in WinAPI, POSIX, or in other extensions of API-OS equivalents to all levels of memory barriers from C++11?

本文关键字：C++11 内存 存在 POSIX WinAPI API-OS 等价物 扩展 其他 是否      更新时间：2023-10-16

在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
};

ADDITION:WinAPI中的一个例子是MemoryBarrier（），但它仅相当于std::atomic_thread_fence( std::memory_order_seq_cst );。因为Windows主要在x86系统上工作，在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:中

_ReadBarrier、_WriteBarrier和_ReadWriteBarrier编译器内部函数只防止编译器重新排序。防止CPU重新排序读取和写入操作，请使用MemoryBarrier宏。

GCC内置函数用于内存模型感知原子操作：

__ATOMIC_RELAXED无障碍或同步。

__ATOMIC_CONSUME仅用于屏障和与另一个线程同步的数据依赖关系。

__ATOMIC_ACQUIRE阻碍代码的提升，并与来自另一个线程的发布（或更强）语义存储同步。

__ATOMIC_RELEASE阻止代码下沉，并与从另一个线程获取（或更强）语义负载同步。

__ATOMIC_ACQ_REL双向全屏障，并与另一个线程中的获取加载和释放存储同步。

__ATOMIC_SEQ_CST双向全屏障，并与所有线程中的获取加载和释放存储同步。

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

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

例如，Visual Studio编译器有_ReadBarrier、_ReadWriteBarrier和_WriteBarrier。（我只链接了一个，因为从那个页面到其他页面都有链接。不，这些不是你列出的所有级别，但它们都是x86的级别……std::memory_order中的列表也涵盖了一堆其他架构。[很明显，memory_order_relaxed"什么都没有"]。

GCC有一种不同类型的内置功能，其目的是提供原子更新，而不是专门的屏障。

然而，一般来说，我会让编译器/OS来处理原子事物——使用std::atomic<>和类似的东西。

几乎可以肯定不是。该标准的目标是覆盖所有偶然性；指定所需的最小值编译器在其环境中提供满足要求。

至于编译器优化：我想编译器可以将这些参数求值为原子函数，并使优化取决于它，但我怀疑大多数编译器将使用一个简单得多的规则：不重新排序内存访问（在编译器级别）与对原子的访问交叉类型

我不确定你想要什么编译器优化使残废如果编译器符合Posix，它将禁用所有内存访问的重新排序CCD_ 11功能；可能会跨越整个系统功能。（想象一下，如果它重新排序了对缓冲区的写入在对write的调用之后，或者在调用read。）

相关文章：