writer starvation

Starvation is when a thread is ready to run and waiting for a resource, but the way the system hands out that resource keeps passing it over, so it waits indefinitely. Writer starvation is the specific, famous case inside the readers-writers problem: a thread wanting to write is forever postponed because readers keep cutting ahead of it. Think of someone trying to merge onto a highway from an on-ramp during rush hour — if the policy is 'cars already on the highway never have to yield,' and the highway never empties, the merging car may sit there all day. It is not blocked by a bug; it is blocked by an unfair policy.

It arises directly from reader-preference. In that solution a reader can enter as long as no writer is currently writing — and crucially, it does not check whether a writer is waiting. So if reads overlap (one reader is still inside when the next arrives), the reader count never drops to zero, the writer lock is never released, and the waiting writer never gets its turn. Importantly, this is not deadlock: the readers are making progress and finishing their work just fine. Only the writer is stuck. That distinction matters — deadlock freezes everyone, starvation singles out a victim.

The cures all amount to introducing fairness. Writer-preference blocks any new reader from entering once a writer is waiting, which guarantees the writer eventually runs (but can then starve readers instead). A fair or FIFO scheme serves requests roughly in arrival order, bounding everyone's wait. The general OS lesson, which shows up far beyond this one puzzle, is that mutual exclusion alone is not enough — a correct concurrent design must also promise bounded waiting, the guarantee that no thread waits forever.