Reader-Writer Lock versus Mutex - Understanding a Lost Bet
summary
A controlled Linux benchmark simulates back-to-back access to a shared map (load ≈300 math ops) and compares do-nothing, a single atomic operation, pthread reader-writer, a lightweight losing implementation and a novel winning implementation that combines a mutex, a semaphore and fast reacquire logic. The surprising result: the initial rwlock loses to a mutex for 90% reads with short lock-hold times, but the winning implementation beats the mutex in 10 scenarios, ties in 8, and only loses in 2; Sun and macOS show platform-specific outliers.
AI-written summary · about
chapters (9)
- 0:00Intro
- 0:13DEFINITIONS
- 10:12MANAGING EXPECTATIONS
- 12:03COST OF ONE ATOMIC
- 20:26COST OF MUTEX AND SEMAPHORE
- 21:44DESIGN CRITERIA
- 23:06LOSING IMPLEMENTATION
- 34:15WINNING IMPLEMENTATION
- 39:11LINUX RECAP
related talks
28mAre mutexes slow?
01h 06mLocks are tricky — let's understand them by building one
01h 38mLock-free Programming is Dead - Long Live Lock-free Programming!
43mWhen Atomics Lose - Architecture‑Dependent Performance of C++ Synchronization
19mWould 'reserve'/'upgrade'/'downgrade' Methods Improve 'std::shared_mutex'?
25mTackling Contention : The Monster in sync.Locker
21mBRAVO—Biased Locking for Reader-Writer Locks
01h 12mThe speed of concurrency (is lock-free faster?)