Using weakly ordered C++ atomics correctly
summary
Most code uses mutexes; atomics are for interrupt handlers or high-performance hotspots, and sequentially consistent atomics give a simpler model at the cost of fence overhead (tens of cycles, cheaper on x86, worse on ARMv7). The useful relaxed options are memory_order_relaxed for per-word counters/harmless diagnostics and acquire/release for publish/subscribe and double-checked initialization. Pitfalls: store→load reordering, compiler-moving loads into critical sections, dependence-based ordering myths, and subtle reference-count and RCU ordering bugs. Use library implementations whenever possible.
AI-written summary · about
chapters (26)
- 0:00Introduction
- 0:21Why atomics
- 3:26Before C11
- 5:07C11 atomics
- 7:46Implementation guarantees
- 10:09Simple examples
- 12:42Another example
- 14:15Costs
- 16:25Performance gap
- 18:32Memory order relaxation
- 21:07Warnings
- 25:28Atomicity
- 26:48Ordering constraints
- 27:14Limitations
- 29:02Critical Section
- 31:34Dependencies
- 34:28General use
- 35:36Disclaimer
- 35:47Single location data structures
- 38:44Double check locking
- 41:19Quiet release
- 43:30Simple locks
- 45:14Reference counting
- 49:08Explicit fence
- 52:30Only the reader
- 54:40Conclusions
related talks
01h 01m“C++11/14/17 atomics and memory model..."
01h 28mAtomic’s memory orders, what for?
01h 03mSafety: off --- How not to shoot yourself in the foot with C++ atomics
01h 14m“C++ atomics, from basic to advanced. What do they really do?”
01h 22mBeyond Sequential Consistency - Leveraging Atomics for Fun & Profit
43mWhen Atomics Lose - Architecture‑Dependent Performance of C++ Synchronization
39mRust Atomics in the Wild: Memory Ordering Design Patterns [...]
43mC++ Atomics...