Are mutexes slow?
summary
Empirical test uses a shared counter: a mutex falls from about 300M ops/s on one thread to ~20M ops/s on two threads (≈10x collapse) because cache-coherency (the MESI protocol) forces cross-core cache-line invalidations (~30 ns each). A conventional reader-writer lock also collapses because readers update a shared counter. A left-right crate duplicates state, uses per-reader padded counters to avoid cache-line bouncing, scales linearly (up to ~150x faster versus RW-lock at many readers) but costs 2x memory, single writer semantics, and eventual-consistency trade-offs.
AI-written summary · about
chapters (8)
- 0:00Mutex performance intro
- 1:06Testing shared counter
- 4:18Mutexes with multiple threads
- 8:55Reader-writer locks and writes
- 13:54Critical sections overhead
- 15:16Left-right data structure
- 24:22Choosing concurrency tool
- 27:29Q&A
related talks
42mReader-Writer Lock versus Mutex - Understanding a Lost Bet
25mTackling Contention : The Monster in sync.Locker
01h 12mThe speed of concurrency (is lock-free faster?)
01h 14m“C++ atomics, from basic to advanced. What do they really do?”
19mWould 'reserve'/'upgrade'/'downgrade' Methods Improve 'std::shared_mutex'?
48m“Is Parallel Programming still hard? PART 2 of 2”
43mWhen Atomics Lose - Architecture‑Dependent Performance of C++ Synchronization
01h 22mBeyond Sequential Consistency - Leveraging Atomics for Fun & Profit