How can a writer be starved when a lock has shared and exclusive modes, and what admission policies exist to prevent it?

## Why starvation is possible at all A writer needs the lock empty. Readers, by design, come and go independently and can overlap. That means the reader count is a value that only reaches zero if the arrival pattern lets it. The question every readers-writer lock must answer is the **admission rule**: when a writer is waiting and a new reader arrives while other readers are inside, do we let the newcomer in? The answer defines the policy. ## Reader preference Admit the reader whenever the lock is not exclusively held. Advantages: maximum read throughput, simplest fast path, no reader ever waits for another reader. Failure mode: with a sustained read rate high enough that read intervals overlap, the count never hits zero and the queued writer waits forever. This is **starvation** — a liveness failure, not a safety one. Nothing is corrupted and readers are perfectly happy, which is exactly why it is hard to notice. It typically appears in production as stale data (the refresh task never gets to run) or as a slowly growing write queue, rather than as an obvious hang. A classic real symptom: a config cache is refreshed by a background writer, request threads read constantly, and under peak traffic the refresh silently stops happening; the data goes stale for the whole peak and updates itself once load drops. ## Writer preference Once a writer is queued, block newly arriving readers behind it. Existing readers drain, the writer runs, then readers resume. This bounds writer latency, at three costs: 1. **Reader latency spikes** — every arriving reader waits out the write section. 2. **Writer floods can starve readers** — the mirror image, if writers keep arriving. 3. **Read-mode re-entry becomes deadlock-prone.** Suppose a thread holds shared mode and, deeper in its call stack, acquires shared mode again. Under reader preference that succeeded. Under writer preference, if a writer queued in between, the second shared acquire blocks behind that writer, while the writer blocks behind the thread's own first shared hold. The thread deadlocks against itself through the writer. This is why recursive read acquisition is documented as unsafe for many writer-preferring locks, and why nested read sections are a smell. ## Fair (FIFO) and phase-fair policies **Fair / FIFO**: put every request, shared or exclusive, into one arrival-ordered queue. Consecutive readers at the head are granted as a batch (they are mutually compatible), so you keep some read parallelism while guaranteeing bounded waiting for everyone. Cost: a reader arriving behind a queued writer waits even though the lock is currently held only in shared mode, so peak read throughput drops. **Phase-fair**: alternate phases explicitly — a reader phase admits all readers waiting at the phase start, then a writer phase admits one writer, and so on. This bounds both reader and writer waits regardless of arrival rates, which is why it is favoured in real-time systems where a worst-case bound must exist. ## How to choose, and how to detect the problem - If writes carry freshness requirements (config refresh, invalidation, index updates), do not use reader preference. A stalled writer means stale data for everyone. - If writes are rare and non-urgent and read throughput is the objective, reader preference is acceptable — but instrument it. - If you need predictability, choose fair or phase-fair and accept lower peak read throughput. - Some implementations offer a middle ground equivalent to bounded barging: allow reader overtaking until a writer has waited N grants or T milliseconds, then switch to writer preference. This preserves most throughput while capping writer latency. Detection is straightforward once you look: record time-to-acquire for exclusive mode as a histogram, and alert on the maximum, not the mean. A starving writer shows up as an unbounded tail on that one metric while everything else looks healthy. Also watch for a rising 'time since last successful write' on any refresh path. One more design escape: if the writer is only refreshing data, you can avoid the contest entirely by having the writer build a new copy off-lock and swap it in under a very short exclusive section — the writer then needs the lock for nanoseconds, so even a reader-preferring policy will let it in.