Reader-Writer Lock versus Mutex
summary
Claim: a mutex often outperforms a reader‑writer lock in high‑contention, short‑hold regimes. Evaluation uses Linux multi‑platform benchmarks with synthetic busy‑wait loads (e.g. 100 ≈ 300 math operations, 10,000 ≈ 30k math operations), reveals that one atomic write kills scalability once several cores contend, and that an initial RW implementation lost the bet to a mutex. A redesigned RW lock minimizes atomics, inherits mutex handoff fairness via a semaphore, and then outperforms mutex for long‑hold or high‑read workloads while only modestly losing where mutex should win.
AI-written summary · about
chapters (15)
- 0:00Intro
- 0:51DEFINITIONS
- 3:17YOU MUST BE JOKING... SHALL WE BET?
- 6:00BENCHMARK DETAILS
- 8:52MANAGING EXPECTATIONS
- 10:22COST OF ONE ATOMIC
- 15:58COST OF MUTEX AND SEMAPHORE
- 17:20DESIGN CRITERIA
- 19:37LOSING IMPLEMENTATION
- 31:11GOAL
- 31:47WINNING IMPLEMENTATION
- 42:14LINUX RECAP
- 43:05SUNOS
- 44:00DARWIN
- 44:49SUMMARY
related talks
52mBest Practices for Concurrency
11mLightning talk: ArcShift: Going faster than RwLock
59mMultithreading 101: Concurrency Primitives From Scratch
01h 00mLock-Free Programming (or, Juggling Razor Blades), Part I
01h 02mA Lock-Free Atomic Shared Pointer in Modern Cpp
39mRust Atomics in the Wild: Memory Ordering Design Patterns [...]
01h 05mIntroduction to Wait-free Algorithms in C++ Programming
01h 04mConcurrency TS2: Improved C++ Concurrency and Lock-free Programming