Synchronization Patterns • Read-Write LocksHard⏱️ ~2 min
Writer Starvation Problem
Key Problem
In the basic solution, writers can starve. If readers keep arriving before existing readers leave, a writer might wait forever.
How Starvation Happens
Reader 1 enters. Reader 2 enters. Writer arrives and waits. Reader 3 enters (readers can enter while others are inside). Reader 1 leaves. Reader 4 enters. Reader 2 leaves. Reader 5 enters... The writer never gets a chance because there is always at least one reader inside.
Writer Starvation Timeline
Not Deadlock, But Still Bad
This is not deadlock - readers are making progress. But the writer is stuck indefinitely. Under high read load, writes never happen. Your database update never commits. Your configuration change never applies.
When Starvation Occurs
High read rate: Readers arrive faster than they leave. Always at least one reader present.
Long read times: Even moderate arrival rate, if reads take a while, overlap increases.
Reader-preference lock: The basic implementation favors readers by design.
Real Impact: A web server that caches config in a read-write lock. Config update waits for all request handlers to finish. Under load, requests overlap continuously. Config never updates until traffic drops.
💡 Key Takeaways
✓Writer starvation: continuous reader arrivals prevent writers from ever entering. Not deadlock, but indefinite waiting.
✓Happens when new readers arrive before existing readers leave. The reader count never drops to zero.
✓High read rate or long read times increase overlap, making starvation more likely.
✓Basic read-write lock implementation has reader preference. Good for throughput, bad for writer fairness.
✓Starvation can make critical operations (config updates, schema changes) impossible under load.
📌 Interview Tips
1Config reload: Server reads config for every request. Config update starves until traffic stops. May never happen.
2Cache invalidation: Cache read is fast but frequent. Cache clear waits indefinitely because reads never stop.