Lock Contention
Lock contention is when multiple threads try to acquire the same lock at the same time, so all but one block and wait. Most of the time threads spend on locking is spent waiting, not holding. From ECE459 L11.
Why does it matter?
A program with locks doesn’t slow down because locks are expensive to acquire. It slows down because threads sit idle waiting for the holder to finish. Every waiting thread is parallelism you paid for and aren’t using.
Three ways to reduce it:
- Shrink the critical section. Move non-shared work out of the guarded scope. The L11 producer-consumer example dropped from 2.8 s to 1.1 s just from tighter scoping
- Split the lock. Fine-grained locking granularity — one lock per record instead of one per table. See also Hash Map Locks
- Drop the lock. Lock-free or atomic primitives when the data structure allows
Contention can degenerate
Under the wrong scheduling pattern a contended lock becomes a lock convoy: the holder gets preempted, every waiter piles up, and the system burns its CPU budget on context switches instead of useful work.