Would 'reserve'/'upgrade'/'downgrade' Methods Improve 'std::shared_mutex'?
summary
Implements a competitive reserve/upgrade variant of std::shared_mutex on Linux, runs a microbenchmark that times completed jobs (80th percentile) while sweeping number of threads, percent reads, and lock hold time, and compares against std::mutex and std::shared_mutex. Finds short hold times make plain mutex often faster, the split reserve→upgrade helps when reads dominate (e.g. ~90%+ reads or writes ~10% → noticeable gains), the version that never blocks new readers performs poorly, and downgrade shows little real‑world benefit.
AI-written summary · about
chapters (9)
- 0:00Intro
- 0:12Pre-Introduction: std::shared_mutex
- 1:18Recent Scenarios
- 3:05std::shared_mutex::lock
- 5:08So why is this not part of the C++ Standard?
- 7:18Micro-Benchmark
- 9:02std::shared_mutex vs. std::mutex
- 14:32What happened to downgrade?
- 15:07Conclusion
related talks
28mAre mutexes slow?
42mReader-Writer Lock versus Mutex - Understanding a Lost Bet
01h 05m“The Continuing Future of C++ Concurrency"
01h 14m“C++ atomics, from basic to advanced. What do they really do?”
55m “High Performance C++ Concurrent Transactional Data Structures"
25mTackling Contention : The Monster in sync.Locker
01h 08mBetter Code: Concurrency
01h 07mThe C++20 Synchronization Library