I read memory-order things in .In the 'Explanation' section, an example is given,

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

and it says

...In particular, this may occur if D is completed before C in thread 2, either due to compiler reordering or at runtime

I'm wondering that as C is sequenced-before D, how could compiler reorder C and D?

From , the definition of sequenced-before guarantees that both value computation and side effect of an expression A will be completed before another expression B if A is sequenced-before B.

I read memory-order things in https://en.cppreference/w/cpp/atomic/memory_order.In the 'Explanation' section, an example is given,

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

and it says

...In particular, this may occur if D is completed before C in thread 2, either due to compiler reordering or at runtime

I'm wondering that as C is sequenced-before D, how could compiler reorder C and D?

From https://en.cppreference/w/cpp/language/eval_order, the definition of sequenced-before guarantees that both value computation and side effect of an expression A will be completed before another expression B if A is sequenced-before B.

• c++

1 Answer 1

In C++, sequenced-before defines the evaluation order within a thread, but it does not guarantee that the actual execution order of independent operations will match the source code order when using relaxed memory ordering. With std::memory_order_relaxed, no synchronization or ordering guarantees are imposed between atomic operations. The compiler/CPU may freely reorder operations on different variables if there are no data dependencies. For example:

// Thread 2:
r2 = x.load(std::memory_order_relaxed); // C
y.store(42, std::memory_order_relaxed); // D

Operations C (load from x) and D (store to y) are independent:

• C does not affect the value stored in D (no data dependency).
• The compiler/CPU can reorder D before C because the reordering is invisible to the thread itself (no observable change in behavior).

To conclude my explanation: Sequenced-before ensures intra-thread consistency but does not prevent the compiler/CPU from reordering independent operations when using relaxed atomics. This allows D to complete before C in Thread 2, even though C is sequenced-before D in the source code.