Versions

[{“Name”:“C++11”,“GroupName”:null},{“Name”:“C++14”,“GroupName”:null},{“Name”:“C++17”,“GroupName”:null}]

Remarks

Different threads trying to access the same memory location participate in a data race if at least one of the operations is a modification (also known as store operation). These data races cause undefined behavior. To avoid them one needs to prevent these threads from concurrently executing such conflicting operations.

Synchronization primitives (mutex, critical section and the like) can guard such accesses. The Memory Model introduced in C++11 defines two new portable ways to synchronize access to memory in multi-threaded environment: atomic operations and fences.

Atomic Operations

It is now possible to read and write to given memory location by the use of atomic load and atomic store operations. For convenience these are wrapped in the std::atomic<t> template class. This class wraps a value of type t but this time loads and stores to the object are atomic.

The template is not available for all types. Which types are available is implementation specific, but this usually includes most (or all) available integral types as well as pointer types. So that std::atomic<unsigned> and std::atomic<std::vector<foo> *> should be available, while std::atomic<std::pair<bool,char>> most probably wont be.

Atomic operations have the following properties:

• All atomic operations can be performed concurrently from multiple threads without causing undefined behavior.
• An atomic load will see either the initial value which the atomic object was constructed with, or the value written to it via some atomic store operation.
• Atomic stores to the same atomic object are ordered the same in all threads. If a thread has already seen the value of some atomic store operation, subsequent atomic load operations will see either the same value, or the value stored by subsequent atomic store operation.
• Atomic read-modify-write operations allow atomic load and atomic store to happen without other atomic store in between. For example one can atomically increment a counter from multiple threads, and no increment will be lost regardless of the contention between the threads.
• Atomic operations receive an optional std::memory_order parameter which defines what additional properties the operation has regarding other memory locations.

std::memory_order | Meaning ––––––––––––––|———————–– std::memory_order_relaxed | no additional restrictions std::memory_order_release → std::memory_order_acquire | if load-acquire sees the value stored by store-release then stores sequenced before the store-release happen before loads sequenced after the load acquire std::memory_order_consume | like memory_order_acquire but only for dependent loads std::memory_order_acq_rel | combines load-acquire and store-release std::memory_order_seq_cst | sequential consistency

These memory order tags allow three different memory ordering disciplines: sequential consistency, relaxed, and release-acquire with its sibling release-consume.

Sequential Consistency

If no memory order is specified for an atomic operation, the order defaults to sequential consistency. This mode can also be explicitly selected by tagging the operation with std::memory_order_seq_cst.

With this order no memory operation can cross the atomic operation. All memory operations sequenced before the atomic operation happen before the atomic operation and the atomic operation happens before all memory operations that are sequenced after it. This mode is probably the easiest one to reason about but it also leads to the greatest penalty to performance. It also prevents all compiler optimizations that might otherwise try to reorder operations past the atomic operation.

Relaxed Ordering