Atomic break down: understanding ordering
summary
Demonstrates a concrete bug where a relaxed atomic flag on an ARM laptop lets a reader see the flag true before the accompanying data is visible, causing a failing assert when run in a loop. Shows the specific fix: use a release store on the writer and an acquire load on the reader so the data write release acquire synchronizes with the reader and guarantees visibility. Notes when relaxed ordering or sequential consistency are appropriate.
AI-written summary · about
chapters (19)
- 0:00Introduction
- 1:50Memory ordering in atomics
- 5:24Single-threaded assumptions
- 7:50Reordering in multi-threaded code
- 10:56Caches and memory visibility
- 12:59C++20 vs Rust memory model
- 14:26Fixing with release-acquire
- 17:17When to use release-acquire
- 19:23RMW with acquire-release
- 20:25When release-acquire fails
- 22:30Sequentially consistent ordering
- 23:56When relaxed ordering works
- 25:41Mutexes and memory ordering
- 26:43Memory ordering choices
- 27:46Further reading
- 28:09Q&A: Performance vs correctness
- 30:16Q&A: Check data before flag
- 30:58Q&A: Guaranteed visibility with acquire
- 32:00Q&A: Debugging reordering
related talks
01h 28mAtomic’s memory orders, what for?
01h 03mUsing weakly ordered C++ atomics correctly
39mRust Atomics in the Wild: Memory Ordering Design Patterns [...]
01h 03mSafety: off --- How not to shoot yourself in the foot with C++ atomics
01h 01mThe two memory models
59mA Relaxed Guide to memory_order_relaxed
01h 01m“C++11/14/17 atomics and memory model..."
01h 22mBeyond Sequential Consistency - Leveraging Atomics for Fun & Profit