The C++11 memory ordering parameters for atomic operations specify constraints on the ordering. If you do a store with std::memory_order_release, and a load from another thread reads the value with std::memory_order_acquire then subsequent read operations from the second thread will see any values stored to any memory location by the first thread that were prior … Read more
Just FYI, memory_order_consume (and [[carries_dependency]]) is essentially deprecated because it’s too hard for compilers to efficiently and correctly implement the rules the way C++11 designed them. (And/or because [[carries_dependency]] and/or kill_dependency would end up being needed all over the place.) See P0371R1: Temporarily discourage memory_order_consume. Current compilers simply treat mo_consume as mo_acquire (and thus on … Read more
I’ve often heard that in the .NET 2.0 memory model, writes always use release fences. Is this true? It depends on what model you are referring to. First, let us precisely define a release-fence barrier. Release semantics stipulate that no other read or write appearing before the barrier in the instruction sequence is allowed to … Read more
The spinlock mutex implementation looks okay to me. I think they got the definitions of acquire and release completely wrong. Here is the clearest explanation of acquire/release consistency models that I am aware of: Gharachorloo; Lenoski; Laudon; Gibbons; Gupta; Hennessy: Memory consistency and event ordering in scalable shared-memory multiprocessors, Int’l Symp Comp Arch, ISCA(17):15-26, 1990, … Read more
On implementations with a flat memory model (basically everything), casting to uintptr_t will Just Work. (But see Should pointer comparisons be signed or unsigned in 64-bit x86? for discussion of whether you should treat pointers as signed or not, including issues of forming pointers outside of objects which is UB in C.) But systems with … Read more
As I understand this is covered in: 1.10 Multi-threaded executions and data races Para 5: The library defines a number of atomic operations (Clause 29) and operations on mutexes (Clause 30) that are specially identified as synchronization operations. These operations play a special role in making assignments in one thread visible to another. A synchronization … Read more
The std::memory_order values allow you to specify fine-grained constraints on the memory ordering provided by your atomic operations. If you are modifying and accessing atomic variables from multiple threads, then passing the std::memory_order values to your operations allow you to relax the constraints on the compiler and processor about the order in which the operations … Read more
You are thinking in terms of sequential consistency, the strongest (and default) memory order. If this memory order is used, all accesses to atomic variables constitute a total order, and the assertion indeed cannot be triggered. However, in this program, a weaker memory order is used (release stores and acquire loads). This means, by definition … Read more
http://en.cppreference.com/w/cpp/atomic/memory_order has a good example at the bottom that only works with memory_order_seq_cst. Essentially memory_order_acq_rel provides read and write orderings relative to the atomic variable, while memory_order_seq_cst provides read and write ordering globally. That is, the sequentially consistent operations are visible in the same order across all threads. The example boils down to this: bool … Read more
Question 1 No. memory_order_relaxed imposes no memory order at all: Relaxed operation: there are no synchronization or ordering constraints, only atomicity is required of this operation. While memory_order_consume imposes memory ordering on data dependent reads (on the current thread) A load operation with this memory order performs a consume operation on the affected memory location: … Read more