What we learned from C++ atomics and memory model standardization
summary
C++ codebases show atomics as common as mutexes, with many using weakly ordered atomics rather than clever lock‑free structures; measurements on ARM cores show seq_cst often not significantly slower than relaxed loads; memory_order_consume is effectively broken and unused; the out‑of‑thin‑air issue leaves relaxed atomics unprovably safe; acquire/release interaction with seq_cst remains confusing and buggy; RISC‑V revealed a real-world RISC-V mapping incompatibility where ABI choices block future instruction additions.
AI-written summary · about
chapters (20)
- 0:00Introduction
- 0:35My background
- 1:06The basic C model
- 1:51Restricting sequential consistency
- 2:13The guarantee
- 2:34Sequential consistency
- 3:46C rule
- 4:49Sequential execution
- 5:34Synchronization Primitives
- 8:51Does this make sense
- 10:05Arm benchmarks
- 11:59C memory model
- 12:25Minor issues
- 13:35Confusion
- 14:11Conventions
- 15:22Im running out of time
- 16:56More serious theoretical issues
- 17:23One mistake we made
- 18:16Oops
- 18:44Questions
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
58m“No Sane Compiler Would Optimize Atomics"
42mThe C++ Execution Model