Dealing With Contention hard
How does a Ticket Lock ensure fairness?
- A Like a deli counter. Threads take a ticket (fetch-and-add). The lock holds a 'Serving' number. Threads spin until Ticket == Serving. This guarantees FIFO order.
- B It uses random numbers.
- C It uses checking accounts.
- D It blocks indefinitely.
Answer: A. Like a deli counter. Threads take a ticket (fetch-and-add). The lock holds a 'Serving' number. Threads spin until Ticket == Serving. This guarantees FIFO order.
Simple and Fair. But suffers from massive cache coherence traffic as all threads spin on the same 'Serving' variable.
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: