阅读中文版本

Lock Fairness and Starvation

Fairness policies decide whether a lock is granted to the longest waiter or to whichever thread arrives fastest, trading throughput for predictable latency.

Definition

Lock fairness is the property that waiters acquire a lock in a bounded or first-come order, preventing a thread from being perpetually overtaken by newer arrivals.

It is a design choice for mutexes and queues where some callers must make progress under contention. Compared to simpler alternatives, this concept fits best when the trade-off it represents is the one the system actually cares about.

When to use it

A common use case is applying it at the boundary where the cost of getting it wrong is highest, and the scenario usually involves a concrete guarantee the system must uphold. Unlike an ad hoc approach, it makes that guarantee explicit, reviewable, and testable.

How it works

An unfair lock lets an arriving thread grab the lock before a queued waiter, which improves throughput on multicore systems but can indefinitely delay a waiter.

A fair lock transfers ownership in arrival order, reducing variance and latency spikes at the cost of additional handoff overhead.

Trade-offs and alternatives

Choose per workload: interactive paths often benefit from fairness for predictable latency, while batch paths may prefer the higher throughput of barging. The main drawback is the extra complexity it introduces, so the benefit should clearly outweigh that cost before a team adopts it.

Common misconceptions

A persistent misconception is that fair locks are always faster because they avoid barging. Another is that unfair locks guarantee progress for every thread. For example, an engineer who assumes otherwise may design around a guarantee that does not actually exist, which only becomes obvious under load or failure.

Anti-patterns to avoid

Two recurring anti-patterns are to defaulting to fair locks in a hot path without measuring throughput and to allowing unbounded barging that starves a background task. Both tend to surface as hard-to-debug production issues rather than obvious test failures. Related concepts include Coroutines, Software Transactional Memory, Happens-Before Relationship.