cpp/atomic/memory order

Formal description
Inter-thread synchronization and memory ordering determine how evaluations and side effects of expressions are ordered between different threads of execution. They are defined in the following terms:

Sequenced-before
Within the same thread, evaluation A may be sequenced-before evaluation B, as described in evaluation order.

Carries dependency
Within the same thread, evaluation A that is sequenced-before evaluation B may also carry a dependency into B (that is, B depends on A), if any of the following is true @1@ The value of A is used as an operand of B, except
 * @a@ if B is a call to std
 * @b@ if A is the left operand of the built-in, , , or operators.

@2@ A writes to a scalar object M, B reads from M @3@ A carries dependency into another evaluation X, and X carries dependency into B

Modification order
All modifications to any particular atomic variable occur in a total order that is specific to this one atomic variable.

The following four requirements are guaranteed for all atomic operations: @1@ Write-write coherence: If evaluation A that modifies some atomic M (a write) happens-before evaluation B that modifies M, then A appears earlier than B in the modification order of M @2@ Read-read coherence: if a value computation A of some atomic M (a read) happens-before a value computation B on M, and if the value of A comes from a write X on M, then the value of B is either the value stored by X, or the value stored by a side effect Y on M that appears later than X in the modification order of M. @3@ Read-write coherence: if a value computation A of some atomic M (a read) happens-before an operation B on M (a write), then the value of A comes from a side-effect (a write) X that appears earlier than B in the modification order of M @4@ Write-read coherence: if a side effect (a write) X on an atomic object M happens-before a value computation (a read) B of M, then the evaluation B shall take its value from X or from a side effect Y that follows X in the modification order of M

Release sequence
After a release operation A is performed on an atomic object M, the longest continuous subsequence of the modification order of M that consists of

@2@ Atomic read-modify-write operations made to M by any thread

is known as release sequence headed by A

Synchronizes with
If an atomic store in thread A is a release operation, an atomic load in thread B from the same variable is an acquire operation, and the load in thread B reads a value written by the store in thread A, then the store in thread A synchronizes-with the load in thread B.

Also, some library calls may be defined to synchronize-with other library calls on other threads.

Dependency-ordered before
Between threads, evaluation A is dependency-ordered before evaluation B if any of the following is true @1@ A performs a release operation on some atomic M, and, in a different thread, B performs a consume operation on the same atomic M, and B reads a value written by A. @2@ A is dependency-ordered before X and X carries a dependency into B.

Inter-thread happens-before
Between threads, evaluation A inter-thread happens before evaluation B if any of the following is true @1@ A synchronizes-with B @2@ A is dependency-ordered before B @3@ A synchronizes-with some evaluation X, and X is sequenced-before B @4@ A is sequenced-before some evaluation X, and X inter-thread happens-before B @5@ A inter-thread happens-before some evaluation X, and X inter-thread happens-before B

Happens-before
Regardless of threads, evaluation A happens-before evaluation B if any of the following is true: @1@ A is sequenced-before B @2@ A inter-thread happens before B

The implementation is required to ensure that the happens-before relation is acyclic, by introducing additional synchronization if necessary (it can only be necessary if a consume operation is involved, see Batty et al)

If one evaluation modifies a memory location, and the other reads or modifies the same memory location, and if at least one of the evaluations is not an atomic operation, the behavior of the program is undefined (the program has a data race) unless there exists a happens-before relationship between these two evaluations.

{{rrev|since=c++20|

Simply happens-before
Regardless of threads, evaluation A simply happens-before evaluation B if any of the following is true: @1@ A is sequenced-before B @2@ A synchronizes-with B @3@ A simply happens-before X, and X simply happens-before B

Note: without consume operations, simply happens-before and happens-before relations are the same. }}

Strongly happens-before
Regardless of threads, evaluation A strongly happens-before evaluation B if any of the following is true:

Visible side-effects
The side-effect A on a scalar M (a write) is visible with respect to value computation B on M (a read) if both of the following are true: @1@ A happens-before B @2@ There is no other side effect X to M where A happens-before X and X happens-before B

If side-effect A is visible with respect to the value computation B, then the longest contiguous subset of the side-effects to M, in modification order, where B does not happen-before it is known as the visible sequence of side-effects. (the value of M, determined by B, will be the value stored by one of these side effects)

Note: inter-thread synchronization boils down to preventing data races (by establishing happens-before relationships) and defining which side effects become visible under what conditions

Consume operation
Atomic load with or stronger is a consume operation. Note that std imposes stronger synchronization requirements than a consume operation.

Acquire operation
Atomic load with or stronger is an acquire operation. The lock operation on a is also an acquire operation. Note that std imposes stronger synchronization requirements than an acquire operation.

Release operation
Atomic store with or stronger is a release operation. The unlock operation on a is also a release operation. Note that std imposes stronger synchronization requirements than a release operation.