Relaxed atomics are not broken. They are not hard to reason about. This proposed "fix" is misguided and reflects a fundamental error made by C++ when defining t

Relaxed atomics are not broken. They are not hard to reason about. This proposed "fix" is misguided and reflects a fundamental error made by C++ when defining their memory model. The most informative paper on the subject is probably "improved support for bidirectional fences", https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2633.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n26.... There are _two_ different atomic memory models in flight in C++. Relaxed atomic operations are perfect for one and something of a nonsense for the other. One model involves controlling the order of atomic operations within a thread of execution using memory fences. The fences amount to limiting reordering in store buffers or invalidation queues. This is what we had before the C++ memory model, though the operations were called "volatile" then. It's what the hardware ISAs expose, with varying details on cost of different types of fence. This is where relaxed atomic operations are the right thing. The threads do not "synchronise with" one another. The second model involves atomic variables that synchronise with one another in different threads. Mechanism unspecified. As far as I can tell this is largely an invention of the C++ committee based on enthusiasm for methods on class instantiations. The paper linked above seems to be the point where this model accepted that it can't express everything it needs to. It's characterised by memory order annotations on methods on variables and wondering what the compiler is going to do with your code. The "synchronises with" model favoured by C++ can be mechanically translated to the "relaxed with fences" model that the hardware implements. The inverse is not true. One piece of the puzzle I don't have is _why_ this is the state of the art. Given a straightforward, existing model for describing concurrent programming on mutable state, somehow we've ended up with a much more complicated one pasted on top. Which leads to various costs, including this article.