Happens-before¶
Category: Lock-free · Status: stub · Lessons: chapter 02, Shared state
One line: The rule a memory model states for when one thread is guaranteed to see another thread's write: only when synchronization orders the write before the read.
Also called: memory model, Java Memory Model, Go memory model, synchronized before.
How it connects¶
- See also: Data race, Weak memory models and reordering
In each language¶
| Rust | std::sync::atomic ↗ states a memory model for atomic accesses: conflicting accesses are fine only if one happens-before the other |
| Go | The Go Memory Model ↗: happens-before is the transitive closure of sequenced-before and synchronized-before, and each sync type documents what it synchronizes before what |
| C | Memory model ↗: conflicting evaluations are no data race if one happens-before the other, as mtx_unlock does before the next mtx_lock |
| C++ | Multi-threaded executions and data races ↗: releasing a std::mutex happens-before another thread acquires it |
| Java | JLS §17.4.5 Happens-before Order ↗; the java.util.concurrent memory consistency properties ↗ list which actions happen-before which |
| Kotlin | Mutex ↗: an unlock happens-before every later successful lock, like synchronized on the JVM |
Where to read more¶
- In the books: Effective Concurrency in Go, Burak Serdar — ch. 3, 'The Go Memory Model' → 'The happened-before relationship between memory operations'
- In the books: Rust Atomics and Locks, Mara Bos — ch. 3, 'Memory Ordering' → 'Happens-Before Relationship'
- In the books: Hands-On Concurrency with Rust, Brian L. Troutwine — ch. 6, 'Atomics – the Primitives of Synchronization' → 'Memory ordering – happens-before and synchronizes-with'
- Reference: The Go Memory Model ↗