Does boost::atomic act as a hardware memory barrier?

Question

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.

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 ?

What is done by boost::atomic ? a hardware barrier ? flush CPU cache/storage buffer ?

The memory_order_acquire semantic makes a software or hardware berrier ?

Answer 1

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. On the other hand, the Windows desktop APIs only run on 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.

(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.)

Answer 2

What is done by boost::atomic ? a hardware barrier ? flush CPU cache/storage buffer ?

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. (The names of synchronisation relationships are marked with emphasis)

Answer 3

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 (i.e., 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; 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. I haven't dug into it, but I assume Boost satisfies the same constraints as the standard library, and implements those constraints appropriately.