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
Say I write some data, and then I write an indication that the data is now ready. It’s imperative that no other thread who sees the indication that the data is ready not see the write of the data itself. So prior writes cannot move past that write. Say I read that some data is … Read more
std::atomic<double> is supported in the sense that you can create one in your program and it will work under the rules of C++11. You can perform loads and stores with it and do compare-exchange and the like. The standard specifies that arithmetic operations (+, *, +=, &, etc.) are only provided for atomics of “integral … Read more
Simply use: std::atomic<int> id{}; int create_id() { return id++; } See http://en.cppreference.com/w/cpp/atomic/atomic/operator_arith
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 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
I know that the atomic types do not have copy constructors, and I assume that explains why this code does not work. Yes, the error says that quite clearly. Does anybody know a way to actually get this code to work? Instead of copy-initialising from a temporary, which requires an accessible copy constructor: std::atomic<int> order::c … Read more
Your code is attempting to construct a temporary std::atomic_int on the RHS, then use the std::atomic_int copy constructor (which is deleted) to initialise stop, like so: std::atomic_int stop = std::atomic_int(0); That’s because copy-initialisation, as you are performing here, is not quite equivalent to other kinds of initialisation. [C++11: 8.5/16]: The semantics of initializers are as … 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
Does this imply that, ‘there is no case where using a non-lock-free atomic type would be a better choice over using a lock-free atomic type when the latter is available’ ? (Mainly in terms of performance rather than ease-of-use). No. And that is, in general, not true. Suppose you have two cores and three threads … Read more