mo_relaxed is fine for both load and store of a stop flag There’s also no meaningful latency benefit to stronger memory orders, even if latency of seeing a change to a keep_running or exit_now flag was important. IDK why Herb thinks stop.store shouldn’t be relaxed; in his talk, his slides have a comment that says … Read more
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
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
Do I have to use atomic for “exit” bool variable? Yes. Either use atomic<bool>, or use manual synchronization through (for instance) an std::mutex. Your program currently contains a data race, with one thread potentially reading a variable while another thread is writing it. This is Undefined Behavior. Per Paragraph 1.10/21 of the C++11 Standard: The … 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
consume is cheaper than acquire. All CPUs (except DEC Alpha AXP’s famously weak memory model1) do it for free, unlike acquire. (Except on x86 and SPARC-TSO, where the hardware has acq/rel memory ordering without extra barriers or special instructions.) On ARM/AArch64/PowerPC/MIPS/etc weakly-ordered ISAs, consume and relaxed are the only orderings that don’t require any extra … Read more