Taming Mutexes for Concurrency
summary
Describes a production design that replaces daily batch ranking with a real‑time service for Vivino, using fine‑grained RW mutex locking around split/joined segments to avoid global contention. Segments settle around 2000 elements per segment and the largest list reaches six million elements across 4,000 segments. Service sustains about 33 million requests per day with 2.7 million daily updates; wrapping lock acquisition in a single helper object reduces ordering bugs and makes deadlocks testable.
AI-written summary · about
chapters (14)
- 0:00Introduction to mutex challenges
- 1:05Real-world database case study
- 7:10Mutex options and trade-offs
- 10:23Typical locking designs
- 12:32Requirements and initial approach
- 13:16Common locking pitfalls
- 16:35Problems with nested locking
- 17:00Wrapping locks in functions
- 20:37Reducing locking complexity
- 23:08Nested locking order proof
- 23:51Testing for dangling locks
- 25:42Performance metrics overview
- 27:58Conclusion and key advice
- 29:09Q&A session
related talks
26mTackling Contention: The Monsters Inside the 'sync.Locker'
39mLet's talk concurrency
55m “High Performance C++ Concurrent Transactional Data Structures"
28mAre mutexes slow?
25mTackling Contention : The Monster in sync.Locker
01h 03mA Multi-threaded, Transaction-Based Locking Strategy for Containers
01h 02mMaking Games Start Fast: A Story About Concurrency
01h 27mFlash Talks