memory consistency model
**Memory Consistency Models** define the **formal rules governing the order in which memory operations (loads and stores) performed by one processor become visible to other processors in a shared-memory multiprocessor system** — determining what values a load can legally return, which directly affects the correctness of parallel programs and the performance optimizations that hardware and compilers are allowed to perform.
**Why Memory Consistency Matters**
Processor A:
```
STORE x = 1
STORE flag = 1
```
Processor B:
```
LOAD flag → reads 1
LOAD x → reads ???
```
- Under Sequential Consistency: B MUST read x = 1 (operations appear in program order).
- Under Relaxed Consistency: B MIGHT read x = 0 (stores can be reordered!).
- Without understanding the model → race conditions → intermittent, impossible-to-debug failures.
**Consistency Model Spectrum**
| Model | Strictness | Hardware | Performance |
|-------|-----------|----------|------------|
| Sequential Consistency (SC) | Strictest | No reordering | Slowest |
| Total Store Order (TSO) | Store-Store preserved | x86, SPARC | Good |
| Relaxed / Weak Ordering | Few guarantees | ARM, RISC-V, POWER | Fastest |
| Release Consistency | Explicit acquire/release | Programming model | Flexible |
**Sequential Consistency (SC)**
- **Definition** (Lamport, 1979): The result of any execution is the same as if operations of all processors were executed in some sequential order, and operations of each individual processor appear in this sequence in the order specified by its program.
- No reordering of any kind.
- Simple to reason about but severely limits hardware optimization.
**Total Store Order (TSO) — x86**
- Stores can be delayed in a **store buffer** → a processor's own store is visible to it before other processors see it.
- Loads can pass earlier stores (to different addresses).
- Store-store order preserved (stores appear to other CPUs in program order).
- Most x86 programs "just work" because TSO is close to SC.
**Relaxed / Weak Ordering — ARM, RISC-V**
- Hardware can reorder almost any operations (load-load, load-store, store-store, store-load).
- Programmer must insert **memory barriers (fences)** to enforce ordering.
- ARM: `DMB` (Data Memory Barrier), `DSB` (Data Synchronization Barrier).
- RISC-V: `FENCE` instruction.
- More optimization opportunities → higher performance → but harder to program.
**Memory Barriers / Fences**
| Barrier | Effect |
|---------|--------|
| Full fence | No load/store crosses the fence in either direction |
| Acquire | No load/store AFTER acquire moves BEFORE it |
| Release | No load/store BEFORE release moves AFTER it |
| Store fence | Stores before cannot pass stores after |
| Load fence | Loads before cannot pass loads after |
**C++ Memory Order (Language Level)**
- `memory_order_seq_cst`: Sequential consistency (default for atomics).
- `memory_order_acquire`: Acquire semantics.
- `memory_order_release`: Release semantics.
- `memory_order_relaxed`: No ordering guarantee (only atomicity).
- Compiler maps these to appropriate hardware barriers for each architecture.
Memory consistency models are **the foundation of correct parallel programming** — understanding the model of your target architecture is essential because code that works correctly on x86 (TSO) may silently produce wrong results on ARM (relaxed), making memory ordering one of the most subtle and critical aspects of concurrent system design.