Weak memory models and reordering¶
Category: Hazards · Status: stub · Lessons: chapter 02, Shared state
One line: CPUs and compilers may perform memory reads and writes in a different order from the source code, and without synchronization another thread can see that order.
Also called: weak ordering, compiler reordering, store buffering.
How it connects¶
- See also: Data race, Happens-before
In each language¶
| Rust | atomic::Ordering ↗: Relaxed, Release, Acquire, AcqRel and SeqCst choose how strongly each atomic operation synchronizes memory |
| Go | The Go Memory Model ↗ defines happens-before from sequenced-before and synchronized-before, and tells programs to serialize shared access rather than reason about the rest |
| C++ | std::memory_order ↗: atomic operations default to sequentially consistent ordering, which can cost performance |
| Java | JLS §17.4 Memory Model ↗; the java.util.concurrent memory consistency properties ↗ list what happens-before what: unlocking a monitor, volatile writes, Thread.start and join |
Where to read more¶
- In a sibling library: Rust: Data races — the -O2 build that hides one ↗
- In the books: Effective Concurrency in Go, Burak Serdar — ch. 3, 'The Go Memory Model'
- In the books: Rust Atomics and Locks, Mara Bos — ch. 3, 'Memory Ordering'
- In the books: C++ Concurrency in Action, Anthony Williams — ch. 5, 'The C++ memory model and operations on atomic types'
- In the books: Java Concurrency in Practice, Brian Goetz, Tim Peierls, Joshua Bloch, Joseph Bowbeer, David Holmes, Doug Lea — ch. 16, 'The Java Memory Model'
- In the books: Learning Concurrent Programming in Scala, Aleksandar Prokopec — ch. 2, 'Concurrency on the JVM and the Java Memory Model'
- In the books: Concurrent Programming on Windows, Joe Duffy — ch. 10, 'Memory Models and Lock Freedom'
- Notes: Weak ordering ↗
- Notes: weak memory model - C++ ↗
- Notes: Compiler Reordering ↗