memory consistency model
**Memory Consistency Models** define the **contractual rules governing the order in which memory operations (loads and stores) from different threads become visible to each other — where the choice between strict sequential consistency and relaxed models (TSO, release-acquire, relaxed) determines both the correctness guarantees available to the programmer and the performance optimizations the hardware and compiler are permitted to make**.
**Why Consistency Models Exist**
Modern processors reorder memory operations for performance: store buffers delay writes, out-of-order execution completes loads before earlier stores, and compilers rearrange memory accesses. Without a model defining which reorderings are legal, multi-threaded programs would have unpredictable behavior across different hardware.
**Key Models (Strongest to Weakest)**
- **Sequential Consistency (SC)**: All threads observe memory operations in a single total order consistent with each thread's program order. The simplest model — behaves as if one operation executes at a time, interleaved from all threads. No hardware implements pure SC efficiently because it forbids almost all reordering.
- **Total Store Ordering (TSO)**: Stores are delayed in a store buffer (a store may not be visible to other threads immediately), but loads always see the most recent value. The ONLY allowed reordering: a load can complete before an earlier store (to a different address) is visible. x86/x64 implements TSO — the strongest model in widespread use.
- **Release-Acquire**: Acquire operations (loading a lock or flag) guarantee that all subsequent reads see values written before the corresponding release (storing the lock or flag) on another thread. Only paired acquire/release operations are ordered; other accesses may be freely reordered. C++11 `memory_order_acquire/release` implements this.
- **Relaxed (Weak Ordering)**: No ordering guarantees on individual loads and stores. The programmer must explicitly insert memory fences/barriers where ordering is required. ARM and RISC-V default to relaxed ordering. Maximum hardware freedom for reordering → highest performance.
**Practical Impact**
```
// Thread 1 // Thread 2
data = 42; while (!ready);
ready = true; print(data); // Must print 42?
```
Under SC: Guaranteed to print 42. Under Relaxed: May print 0 (stale data) because the compiler or hardware may reorder `data = 42` after `ready = true`, or Thread 2 may see `ready` before `data` propagates. Under Release-Acquire: If `ready` is stored with release and loaded with acquire, guaranteed to print 42.
**Fences and Barriers**
- `__sync_synchronize()` (GCC): Full memory fence — no reordering across the fence.
- `std::atomic_thread_fence(memory_order_seq_cst)`: Sequential consistency fence.
- ARM `dmb` / RISC-V `fence`: Hardware memory barrier instructions.
Memory Consistency Models are **the invisible contract between hardware designers and software developers** — defining the boundary between optimizations the hardware may perform silently and ordering guarantees the programmer can rely upon for correct multi-threaded execution.