Make Rider Addition and Dispatch Safe Under Concurrency

A rider-assignment system supports adding available riders and dispatching a rider to work. Identify and fix the concurrency problems that can occur when these operations run simultaneously. ### Constraints & Assumptions The original implementation is not supplied. For a concrete practice model, dispatch any available rider, never assign the same availability entry twice, and make duplicate add calls idempotent while a rider is already available or assigned. Riders are not re-added after assignment in this limited model; completion/reavailability would need an additional lifecycle operation. ### Clarifying Questions What is the rider identity and lifecycle? Is dispatch selection ordered or arbitrary? Can two workers dispatch concurrently? Which state changes must be atomic? Does assignment trigger an external operation? ### What a Strong Answer Covers The shared-state invariant, check-then-act races, one synchronized mutation boundary, lock scope, and deterministic concurrency tests. ### Follow-up Questions Why is checking that a queue is nonempty before locking unsafe? What happens if a rider is removed from the queue but assignment persistence fails? How would the design change across several service instances?