std::memory_order_consume is the most legendary of the six memory models. That's for two reasons. On one hand, std::memory_order_consume is extremely hard to get. On the other hand - that may change in the future - no compiler supports it.

A release operation synchronises with an acquire operation on the same atomic variable and establishes, in addition, ordering constraints. These are the components to synchronise threads in a performant way, in case they act on the same atomic. But how can that work, if two threads share no atomic variable? We want no sequential consistency because that is too heavy. We want the light acquire-release semantic.

With the acquire-release semantic the memory model gets very thrilling. Because now, we have not to reason about the synchronisation of threads, now we have to reason about the synchronisation of the same atomic in different threads.

I have introduced In the post Sequential Consistency the default memory model. This model, in which all operations in all threads takes place in a global time clock, has a big advantage but also a big disadvantage.

In this post, our tour through the c++ memory model goes one step deeper. Until now, the posts were only about the atomicity of the atomic data types but now we deal with the synchronisation and ordering constraints of the operations.

In addition to booleans, there is atomics for pointers, integrals and user-defined types. The rules for user-defined types are special.

The remaining atomics - in contrast to std::atomic_flag - are partial or full specialisations of the class template std::atomic. Let's start with std::atomic<bool>.

Atomics guarantee two characteristics. On one hand, they are atomic, on the other hand, they provide synchronization and order constraints on the program execution.

The atomics are the base of the C++ memory model. Per default, sequential consistency is applied.

Since C++11, C++ has a memory model. It is the foundation for multithreading. Without it, multithreading is not well defined.