std::memory_order specifies how memory accesses, including regular, non-atomic memory accesses, are to be ordered around an atomic operation. Absent any constraints on a multi-core system, when multiple threads simultaneously read and write to several variables, one thread can observe the values change in an order different from the order another thread wrote them. Indeed, the apparent order of changes can even differ among multiple reader threads. Some similar effects can occur even on uniprocessor systems due to compiler transformations allowed by the memory model.

The default behavior of all atomic operations in the library provides forsequentially consistent ordering (see discussion below). That default can hurt performance, but the library's atomic operations can be given an additionalstd::memory_order argument to specify the exact constraints, beyond atomicity, that the compiler and processor must enforce for that operation.

[edit]Constants

[edit]Formal description

Inter-thread synchronization and memory ordering determine howevaluations andside effects of expressions are ordered between different threads of execution. They are defined in the following terms:

[edit]Sequenced-before

Within the same thread, evaluation A may besequenced-before evaluation B, as described inevaluation order.

[edit]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:

[edit]Release sequence

After arelease operation A is performed on an atomic object M, the longest continuous subsequence of the modification order of M that consists of:

Is known asrelease sequence headed by A.

[edit]Synchronizes with

If an atomic store in thread A is arelease operation, an atomic load in thread B from the same variable is anacquire operation, and the load in thread B reads a value written by the store in thread A, then the store in thread Asynchronizes-with the load in thread B.

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

[edit]Inter-thread happens-before

Between threads, evaluation Ainter-thread happens before evaluation B if any of the following is true:

[edit]Strongly happens-before

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

[edit]Visible side-effects

The side-effect A on a scalar M (a write) isvisible with respect to value computation B on M (a read) if both of the following are true:

If side-effect A is visible with respect to the value computation B, then the longest contiguous subset of the side-effects to M, inmodification order, where B does nothappen-before it is known as thevisible 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.

[edit]Consume operation

Atomic load withmemory_order_consume or stronger is a consume operation. Note thatstd::atomic_thread_fence imposes stronger synchronization requirements than a consume operation.

[edit]Acquire operation

Atomic load withmemory_order_acquire or stronger is an acquire operation. Thelock() operation on aMutex is also an acquire operation. Note thatstd::atomic_thread_fence imposes stronger synchronization requirements than an acquire operation.

[edit]Release operation

Atomic store withmemory_order_release or stronger is a release operation. Theunlock() operation on aMutex is also a release operation. Note thatstd::atomic_thread_fence imposes stronger synchronization requirements than a release operation.

[edit]Explanation

[edit]Relaxed ordering

Atomic operations taggedmemory_order_relaxed are not synchronization operations; they do not impose an order among concurrent memory accesses. They only guarantee atomicity and modification order consistency.

For example, withx andy initially zero,

// Thread 1:r1= y.load(std::memory_order_relaxed);// Ax.store(r1, std::memory_order_relaxed);// B// Thread 2:r2= x.load(std::memory_order_relaxed);// Cy.store(42, std::memory_order_relaxed);// D

is allowed to producer1== r2==42 because, although A issequenced-before B within thread 1 and C issequenced before D within thread 2, nothing prevents D from appearing before A in the modification order ofy, and B from appearing before C in the modification order ofx. The side-effect of D ony could be visible to the load A in thread 1 while the side effect of B onx could be visible to the load C in thread 2. In particular, this may occur if D is completed before C in thread 2, either due to compiler reordering or at runtime.

// Thread 1:r1= y.load(std::memory_order_relaxed);if(r1==42)    x.store(r1, std::memory_order_relaxed);// Thread 2:r2= x.load(std::memory_order_relaxed);if(r2==42)    y.store(42, std::memory_order_relaxed);

Typical use for relaxed memory ordering is incrementing counters, such as the reference counters ofstd::shared_ptr, since this only requires atomicity, but not ordering or synchronization (note that decrementing thestd::shared_ptr counters requires acquire-release synchronization with the destructor).

#include <atomic>#include <iostream>#include <thread>#include <vector> std::atomic<int> cnt={0}; void f(){for(int n=0; n<1000;++n)        cnt.fetch_add(1, std::memory_order_relaxed);} int main(){std::vector<std::thread> v;for(int n=0; n<10;++n)        v.emplace_back(f);for(auto& t: v)        t.join();std::cout<<"Final counter value is "<< cnt<<'\n';}

Final counter value is 10000

[edit]Release-Acquire ordering

If an atomic store in thread A is taggedmemory_order_release, an atomic load in thread B from the same variable is taggedmemory_order_acquire, and the load in thread B reads a value written by the store in thread A, then the store in thread Asynchronizes-with the load in thread B.

All memory writes (including non-atomic and relaxed atomic) thathappened-before the atomic store from the point of view of thread A, becomevisible side-effects in thread B. That is, once the atomic load is completed, thread B is guaranteed to see everything thread A wrote to memory. This promise only holds if B actually returns the value that A stored, or a value from later in the release sequence.

The synchronization is established only between the threadsreleasing andacquiring the same atomic variable. Other threads can see different order of memory accesses than either or both of the synchronized threads.

On strongly-ordered systems — x86, SPARC TSO, IBM mainframe, etc. — release-acquire ordering is automatic for the majority of operations. No additional CPU instructions are issued for this synchronization mode; only certain compiler optimizations are affected (e.g., the compiler is prohibited from moving non-atomic stores past the atomic store-release or performing non-atomic loads earlier than the atomic load-acquire). On weakly-ordered systems (ARM, Itanium, PowerPC), special CPU load or memory fence instructions are used.

Mutual exclusion locks, such asstd::mutex oratomic spinlock, are an example of release-acquire synchronization: when the lock is released by thread A and acquired by thread B, everything that took place in the critical section (before the release) in the context of thread A has to be visible to thread B (after the acquire) which is executing the same critical section.

#include <atomic>#include <cassert>#include <string>#include <thread> std::atomic<std::string*> ptr;int data; void producer(){std::string* p= newstd::string("Hello");    data=42;    ptr.store(p, std::memory_order_release);} void consumer(){std::string* p2;while(!(p2= ptr.load(std::memory_order_acquire)));assert(*p2=="Hello");// never firesassert(data==42);// never fires} int main(){std::thread t1(producer);std::thread t2(consumer);    t1.join(); t2.join();}

#include <atomic>#include <cassert>#include <thread>#include <vector> std::vector<int> data;std::atomic<int> flag={0}; void thread_1(){    data.push_back(42);    flag.store(1, std::memory_order_release);} void thread_2(){int expected=1;// memory_order_relaxed is okay because this is an RMW,// and RMWs (with any ordering) following a release form a release sequencewhile(!flag.compare_exchange_strong(expected,2, std::memory_order_relaxed)){        expected=1;}} void thread_3(){while(flag.load(std::memory_order_acquire)<2);// if we read the value 2 from the atomic flag, we see 42 in the vectorassert(data.at(0)==42);// will never fire} int main(){std::thread a(thread_1);std::thread b(thread_2);std::thread c(thread_3);    a.join(); b.join(); c.join();}

[edit]Release-Consume ordering

#include <atomic>#include <cassert>#include <string>#include <thread> std::atomic<std::string*> ptr;int data; void producer(){std::string* p= newstd::string("Hello");    data=42;    ptr.store(p, std::memory_order_release);} void consumer(){std::string* p2;while(!(p2= ptr.load(std::memory_order_consume)));assert(*p2=="Hello");// never fires: *p2 carries dependency from ptrassert(data==42);// may or may not fire: data does not carry dependency from ptr} int main(){std::thread t1(producer);std::thread t2(consumer);    t1.join(); t2.join();}

[edit]Sequentially-consistent ordering

Atomic operations taggedmemory_order_seq_cst not only order memory the same way as release/acquire ordering (everything thathappened-before a store in one thread becomes avisible side effect in the thread that did a load), but also establish asingle total modification order of all atomic operations that are so tagged.

// Thread 1:x.store(1, std::memory_order_seq_cst);// Ay.store(1, std::memory_order_release);// B// Thread 2:r1= y.fetch_add(1, std::memory_order_seq_cst);// Cr2= y.load(std::memory_order_relaxed);// D// Thread 3:y.store(3, std::memory_order_seq_cst);// Er3= x.load(std::memory_order_seq_cst);// F

Sequential ordering may be necessary for multiple producer-multiple consumer situations where all consumers must observe the actions of all producers occurring in the same order.

Total sequential ordering requires a full memory fence CPU instruction on all multi-core systems. This may become a performance bottleneck since it forces the affected memory accesses to propagate to every core.

#include <atomic>#include <cassert>#include <thread> std::atomic<bool> x={false};std::atomic<bool> y={false};std::atomic<int> z={0}; void write_x(){    x.store(true, std::memory_order_seq_cst);} void write_y(){    y.store(true, std::memory_order_seq_cst);} void read_x_then_y(){while(!x.load(std::memory_order_seq_cst));if(y.load(std::memory_order_seq_cst))++z;} void read_y_then_x(){while(!y.load(std::memory_order_seq_cst));if(x.load(std::memory_order_seq_cst))++z;} int main(){std::thread a(write_x);std::thread b(write_y);std::thread c(read_x_then_y);std::thread d(read_y_then_x);    a.join(); b.join(); c.join(); d.join();assert(z.load()!=0);// will never happen}

[edit]Relationship withvolatile

Within a thread of execution, accesses (reads and writes) throughvolatile glvalues cannot be reordered past observable side-effects (including other volatile accesses) that aresequenced-before orsequenced-after within the same thread, but this order is not guaranteed to be observed by another thread, since volatile access does not establish inter-thread synchronization.

In addition, volatile accesses are not atomic (concurrent read and write is adata race) and do not order memory (non-volatile memory accesses may be freely reordered around the volatile access).

One notable exception is Visual Studio, where, with default settings, every volatile write has release semantics and every volatile read has acquire semantics (Microsoft Docs), and thus volatiles may be used for inter-thread synchronization. Standardvolatile semantics are not applicable to multi-threaded programming, although they are sufficient for e.g. communication with astd::signal handler that runs in the same thread when applied tosig_atomic_t variables. The compiler option/volatile:iso can be used to restore behavior consistent with the standard, which is the default setting when the target platform is ARM.

[edit]See also

[edit]External links

• In other languages

• Deutsch
• Español
• Français
• Italiano
• 日本語
• Português
• Русский
• 中文