When everyone wants the same lock
Contention is the situation where multiple threads compete for the same lock at the same time. A lightly contended lock is nearly free; a heavily contended one becomes the bottleneck that decides your whole systems throughput.
What contention costs
- Serialization only one thread runs the protected region at a time, so that region cannot scale no matter how many cores you add
- Cache line bouncing the lock word and the data it guards ricochet between cores, each transfer costing hundreds of cycles
- Convoying threads pile up behind the holder, and if the holder is preempted the whole convoy stalls
- Scheduler overhead with blocking locks, waiters sleep and wake repeatedly
The scalability ceiling
Amdahls law makes this concrete. If a fraction of work is serialized behind one lock, that fraction caps your speedup. Adding cores past the point where the lock saturates can even reduce throughput, because more threads mean more cache traffic and more wakeups fighting over the same word.
Reducing it
The cures are structural: shrink the critical section, split one lock into many, or remove the lock with a lock free design.
Key idea
A contended lock serializes work and thrashes caches, so beyond a point extra cores add traffic instead of throughput.