boost :: atomic是否充当硬件存储屏障？

Question

据我所知，出于性能原因，编译器（软件）和CPU（硬件）将对指令进行重新排序，而内存屏障可以防止重新排序，它们处于编译器级别或CPU级别。

MSDN说：“ Interlockedxxxx函数生成完整的内存屏障（或篱笆）以确保按顺序完成内存操作”，我不知道“完整的内存屏障”是指硬件还是软件屏障？

boost :: atomic是做什么的？ 硬件障碍？ 刷新CPU缓存/存储缓冲区？

memory_order_acquire语义使软件或硬件变得繁琐？

Answer 1

它提供了指定的内存模型，并使用了所用平台所需的任何障碍。

请记住， boost::atomic是可移植的API，具有在许多不同平台上的实现。 另一方面，Windows桌面API仅在Intel上运行。 结果，MSDN文档将具有特定于平台的信息（因为只有三个平台-x86，x64，Itanium），而atomic文档则不会。

（注意：大多数Win32也用于ARM处理器上的Windows CE，但是有一组并行的文档页面。桌面页面不包含ARM。覆盖Windows 8 RT的“ Windows Store” API是另一组文档。）

Answer 2

boost::atomic是做什么的？ 硬件障碍？ 刷新CPU缓存/存储缓冲区？

有关系吗？

原子操作建立同步关系。 他们要做在目标计算机上完成那些关系所定义的行为所需的一切。

例如，具有商店释放语义的操作与具有负载获取语义的操作同步 。 如果操作A 与操作B 同步 ，则说A 线程间发生在 B 之前 ，这意味着A 发生在 B 之前 ，这意味着A和B不会引起数据争用。 （同步关系的名称标有重点）

Answer 3

修改线程之间共享的值时涉及三个问题。 首先，在读取或写入该值的过程中可能会发生线程切换，结果是某些其他线程可能会看到部分写入（即无意义）的值。 其次，每个处理器都有自己的数据缓存，因此，一个处理器上运行的另一个线程可能看不到从一个处理器上的一个线程进行的写操作。 第三，编译器可以在限制范围内对指令重新排序，以使代码更高效。 std::atomic消除了所有三种可能性：原子对象的读取和写入操作不间断； 写入原子类型会将缓存刷新到主内存，而从原子类型读取会从主内存重新加载缓存； 并且不允许编译器在原子类型的操作之间移动指令。 这些操作的完成方式（包括是否需要完成任何操作）的详细信息取决于目标平台，但这都是在标准库的实现中完成的。 编辑：哎呀，只是注意到这个问题问有关Boost的问题。 我没有深入研究它，但是我假设Boost满足与标准库相同的约束，并适当地实现了这些约束。