Dealing With Contention hard
A standard Reader-Writer lock allows multiple readers or one writer. If readers arrive constantly, what happens to the writer?
- A It runs immediately.
- B Writer Starvation. The writer waits for the active readers to drain, but new readers keep arriving and taking the shared lock, so the read-count never hits 0.
- C The writer joins the readers.
- D Deadlock.
Answer: B. Writer Starvation. The writer waits for the active readers to drain, but new readers keep arriving and taking the shared lock, so the read-count never hits 0.
Writer-Preference RW locks solve this by blocking new readers once a writer is waiting.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- Why is 'Exponential Backoff' preferred over constant intervals for retries?
- What is the primary purpose of a Mutex (Mutual Exclusion) lock?
- Why does adding more threads sometimes *decrease* performance?
- In a Saga, if a Compensating Transaction (Undo) fails repeatedly due to contention, what is the last resort?
- In a database, what happens if Transaction A locks a row and Transaction B tries to modify the same row?
- A database restart causes thousands of application servers to instantly try to reconnect. This crashes the DB again. This is called: