[英]Does boost::atomic act as a hardware memory barrier?
As far as I know, compiler(software) and CPU(hardware) will reorder instructions for performance reason, and memory berriers can prevent the reordering, they're in compiler level or CPU level. 据我所知,出于性能原因,编译器(软件)和CPU(硬件)将对指令进行重新排序,而内存屏障可以防止重新排序,它们处于编译器级别或CPU级别。
MSDN says "Interlockedxxxx function generates a full memory barrier (or fence) to ensure that memory operations are completed in order", I don't know "a full memory barrier" means hardware or software barrier ? MSDN说:“ Interlockedxxxx函数生成完整的内存屏障(或篱笆)以确保按顺序完成内存操作”,我不知道“完整的内存屏障”是指硬件还是软件屏障?
What is done by boost::atomic ? boost :: atomic是做什么的? a hardware barrier ?
硬件障碍? flush CPU cache/storage buffer ?
刷新CPU缓存/存储缓冲区?
The memory_order_acquire semantic makes a software or hardware berrier ? memory_order_acquire语义使软件或硬件变得繁琐?
It provides the specified memory model, using whatever barriers are needed for the platform you're using. 它提供了指定的内存模型,并使用了所用平台所需的任何障碍。
Remember that boost::atomic
is a portable API with implementations on many different platforms. 请记住,
boost::atomic
是可移植的API,具有在许多不同平台上的实现。 On the other hand, the Windows desktop APIs only run on Intel. 另一方面,Windows桌面API仅在Intel上运行。 As a result, the MSDN documentation will have platform-specific information (because there's only three platforms -- x86, x64, Itanium) and the
atomic
docs won't. 结果,MSDN文档将具有特定于平台的信息(因为只有三个平台-x86,x64,Itanium),而
atomic
文档则不会。
(NB: Most of Win32 also is used in Windows CE on ARM processors, but there's a parallel set of documentation pages. The desktop pages don't cover ARM. And "Windows Store" APIs that cover Windows 8 RT are yet another set of docs.) (注意:大多数Win32也用于ARM处理器上的Windows CE,但是有一组并行的文档页面。桌面页面不包含ARM。覆盖Windows 8 RT的“ Windows Store” API是另一组文档。)
What is done by
boost::atomic
?boost::atomic
是做什么的? a hardware barrier ?硬件障碍? flush CPU cache/storage buffer ?
刷新CPU缓存/存储缓冲区?
Does it matter? 有关系吗?
Atomic operations establish synchronisation relationships. 原子操作建立同步关系。 They do whatever needs to be done on the target machine to achieve the behaviour defined by those relationships.
他们要做在目标计算机上完成那些关系所定义的行为所需的一切。
For example, operations with store-release semantics synchronise with operations with load-acquire semantics. 例如,具有商店释放语义的操作与具有负载获取语义的操作同步 。 If an operation A synchronises with an operation B, then it is said that A inter-thread happens before B, and that implies that A happens before B, and that means that A and B don't cause data races.
如果操作A 与操作B 同步 ,则说A 线程间发生在 B 之前 ,这意味着A 发生在 B 之前 ,这意味着A和B不会引起数据争用。 (The names of synchronisation relationships are marked with emphasis)
(同步关系的名称标有重点)
There are three issues involved when modifying values that are shared between threads. 修改线程之间共享的值时涉及三个问题。 First, there's the possibility of a thread switch in the middle of reading or writing the value, with the result that some other thread could see a partially written (ie, nonsensical) value.
首先,在读取或写入该值的过程中可能会发生线程切换,结果是某些其他线程可能会看到部分写入(即无意义)的值。 Second, each processor has its own data cache, so writes from one thread on one processor might not be visible to another thread running on another processor.
其次,每个处理器都有自己的数据缓存,因此,一个处理器上运行的另一个线程可能看不到从一个处理器上的一个线程进行的写操作。 Third, the compiler can reorder instructions, within limits, to make code more efficient.
第三,编译器可以在限制范围内对指令重新排序,以使代码更高效。
std::atomic
eliminates all three possibilities: reads and writes of atomic objects are done without interruption; std::atomic
消除了所有三种可能性:原子对象的读取和写入操作不间断; writing to an atomic type flushes the cache to main memory, and reading from an atomic type reloads the cache from main memory; 写入原子类型会将缓存刷新到主内存,而从原子类型读取会从主内存重新加载缓存; and the compiler is not allowed to move instructions across operations on atomic types.
并且不允许编译器在原子类型的操作之间移动指令。 The details of how these things are done (including whether there needs to be anything done) depend on the target platform, but that's all done in the standard library's implementation.
这些操作的完成方式(包括是否需要完成任何操作)的详细信息取决于目标平台,但这都是在标准库的实现中完成的。 EDIT: whoops, just noticed that the question asks about Boost.
编辑:哎呀,只是注意到这个问题问有关Boost的问题。 I haven't dug into it, but I assume Boost satisfies the same constraints as the standard library, and implements those constraints appropriately.
我没有深入研究它,但是我假设Boost满足与标准库相同的约束,并适当地实现了这些约束。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.