Make Token-Bucket Admission Safe Across Threads

A token-bucket-like rate limiter must be usable by **multiple threads**. Explain how you would make the shared limiter state and admission decisions safe under concurrent access. The bucket's capacity, initial balance, refill policy, request cost, and accept-versus-wait behavior have not been specified. Identify which policies must first be agreed on, then explain a concurrency design that preserves those policies. If you use a particular token policy to illustrate the design, label it as an assumption. Focus on the explicitly asked multithreading follow-up within one process. Describe the shared state, the operation that must be atomic, clock handling, and how you would check for races. No executable base-limiter interface is supplied. ### What a Strong Answer Covers - A concrete race that could admit more work than the shared balance permits. - Atomic coordination of refill accounting, availability checks, and token consumption. - A synchronization approach and the point at which each admission decision takes effect. - Handling of waiting, contention, and time observations without changing the agreed rate policy. ### Follow-up Questions - Why is an atomic decrement of the token count alone insufficient? - If a request must wait for tokens, what should happen to the lock while it waits?