Why Does `std::atomic` Use `XCHG` for Sequentially Consistent Stores?

Why std::atomic Uses XCHG for Sequential Consistency Stores

Background

In the realm of multithreading, the std::atomic class provides a means for concurrent access to shared data across threads while ensuring data integrity. Its store member function allows for writing values to an atomic variable with specified memory ordering semantics.

In the case of sequential consistency (std::memory_order_seq_cst), x86 architectures employ an xchg instruction to implement atomic stores. This instruction performs a simultaneous exchange of values rather than a simple store operation.

Motivation for XCHG

While it might appear that a straightforward store instruction coupled with a memory barrier (e.g., _ReadWriteBarrier() or asm volatile("" ::: "memory");) would suffice for sequential consistency, using xchg has several advantages:

1. Full Memory Barrier: xchg acts as a complete memory fence on x86 due to its implicit lock prefix. This ensures that all memory operations before and after xchg are ordered, effectively preventing memory reordering.

2. Release Semantics are Insufficient: A normal store operation on x86 exhibits release semantics, which allows reordering with subsequent operations, including acquire loads. Sequential consistency, on the other hand, demands that such reordering is prohibited.

Performance Considerations

The choice between xchg and mov mfence for atomic stores has performance implications:

• Skylake: mfence stalls out-of-order execution of ALU instructions, while xchg does not. However, xchg carries a false dependency on the previously loaded value.
• AMD: The hardware optimization manual recommends using xchg for sequential consistency stores.
• GCC/Clang Optimization: Modern compilers typically prefer xchg over mov mfence.

Alternative for Thread Fences

Apart from using xchg for atomic stores, other options for implementing atomic thread fences (also with the seq_cst memory ordering) include:

• lock add to the stack
• lock or dword [rsp], 0

Distinguishing Release and Acquire

It is important to note that:

• A store with sequential consistency does not imply acquire semantics.
• asm volatile("" ::: "memory"); is a compiler barrier only and does not enforce sequential consistency.
• Emulating sequential consistency with weaker order operations and fences may not align entirely with the C abstract machine model.

Conclusion

In summary, std::atomic stores with sequential consistency on x86 architectures utilize xchg due to its full memory barrier effect and compatibility with the requirements of sequential consistency. While alternative implementations exist, xchg remains a widely adopted solution for its efficiency and compliance with industry recommendations.

The above is the detailed content of Why Does `std::atomic` Use `XCHG` for Sequentially Consistent Stores?. For more information, please follow other related articles on the PHP Chinese website!