C++ Atomics...
summary
Explains why memory_order_consume is effectively promoted to acquire by production compilers, costing extra fences and killed optimizations, and shows concrete evidence: compilers force volatile casts in current Linux RCU code and a submitted patch saves one non-atomic store and one load with measurable user‑mode benchmark wins. Proposes a small set of Linux kernel patches that remove the hardest use cases, outlines using C11 atomics vs pre‑C11 tricks, and argues these changes plus RCU storage‑class or restricted‑dependency approaches could restore low‑overhead consume.
AI-written summary · about
chapters (12)
- 0:00Introduction to Memory Order
- 1:09Target Workloads
- 3:50Why Memory Order Consume?
- 9:31Importance for Read-Mostly Data
- 13:38Performance and Implementation
- 17:09Safe Data Insertion
- 20:59Data Removal and RCU
- 26:56Social Engineering in Sync
- 28:57Hardware Costs and Scaling
- 34:01RCU in the Linux Kernel
- 36:22Advantages of RCU
- 39:38Future Resolutions and Conclusion
related talks
01h 28mAtomic’s memory orders, what for?
01h 03mUsing weakly ordered C++ atomics correctly
01h 28mC++ Memory Model: from C++11 to C++23
58m“No Sane Compiler Would Optimize Atomics"
01h 14m“C++ atomics, from basic to advanced. What do they really do?”
01h 22mBeyond Sequential Consistency - Leveraging Atomics for Fun & Profit
01h 03mSafety: off --- How not to shoot yourself in the foot with C++ atomics
43mWhen Atomics Lose - Architecture‑Dependent Performance of C++ Synchronization