Implement concurrent order-accept/pickup simulator
Concurrent Restaurant Order and Pickup Simulator
Design and implement a thread-safe simulation for a restaurant system that manages the lifecycle of orders from placement to pickup. The system must support concurrent operations across multiple stages:
- Receiving incoming orders (multiple producer threads).
- Preparing orders (one or more worker/chef threads).
- Allowing customers to pick up orders (multiple consumer threads).
Requirements
-
Order Structure: Each order must have:
order_id: A unique integer identifier.item_name: A string representing the item.cook_time_ms: A positive integer indicating the time required to cook the item in milliseconds.
-
API / Operations: The system must expose the following operations (names can be adapted):
placeOrder(order_id, item_name, cook_time_ms): Submits a new order to the system.startKitchen(num_chefs): Initializes and starts background processing threads for cooking, withnum_chefsspecifying the number of concurrent chef workers.pickupOrder(order_id): Blocks until the specified order is ready for pickup, then returns the order.shutdown(): Gracefully stops all background processing threads.
-
Correctness Constraints:
- An order cannot be picked up before it has been fully cooked.
- Each order must be cooked exactly once.
- Each order can be picked up at most once.
- The system must be free of deadlocks and avoid busy-waiting.
- The design should robustly handle
Nconcurrent order placements and pickups.
Discussion and Implementation Focus
Candidates should be prepared to discuss and implement:
- Their choice of synchronization primitives (e.g., mutexes, locks, condition variables, semaphores, blocking queues).
- The data structures used to track and manage order states throughout their lifecycle.
- Strategies to ensure fairness among waiting orders/customers and prevent race conditions.
Assumptions
- The simulation operates within a single process with shared memory.
- No networking or distributed system concerns are required.
AI interview prep
Core dilemma
Managing complex, multi-stage state transitions for concurrent entities (orders) with strict ordering, uniqueness, and atomicity constraints, while ensuring thread safety, liveness (no deadlocks/busy-waiting), and graceful resource management.
3 tradeoffs and 3 stress tests locked
Interview prep
Unlock the interviewer X-Ray rubric, tradeoff matrix, stress tests, clarifying questions, and key concepts.
Implement concurrent order-accept/pickup simulator
Concurrent Restaurant Order and Pickup Simulator
Design and implement a thread-safe simulation for a restaurant system that manages the lifecycle of orders from placement to pickup. The system must support concurrent operations across multiple stages:
- Receiving incoming orders (multiple producer threads).
- Preparing orders (one or more worker/chef threads).
- Allowing customers to pick up orders (multiple consumer threads).
Requirements
-
Order Structure: Each order must have:
order_id: A unique integer identifier.item_name: A string representing the item.cook_time_ms: A positive integer indicating the time required to cook the item in milliseconds.
-
API / Operations: The system must expose the following operations (names can be adapted):
placeOrder(order_id, item_name, cook_time_ms): Submits a new order to the system.startKitchen(num_chefs): Initializes and starts background processing threads for cooking, withnum_chefsspecifying the number of concurrent chef workers.pickupOrder(order_id): Blocks until the specified order is ready for pickup, then returns the order.shutdown(): Gracefully stops all background processing threads.
-
Correctness Constraints:
- An order cannot be picked up before it has been fully cooked.
- Each order must be cooked exactly once.
- Each order can be picked up at most once.
- The system must be free of deadlocks and avoid busy-waiting.
- The design should robustly handle
Nconcurrent order placements and pickups.
Discussion and Implementation Focus
Candidates should be prepared to discuss and implement:
- Their choice of synchronization primitives (e.g., mutexes, locks, condition variables, semaphores, blocking queues).
- The data structures used to track and manage order states throughout their lifecycle.
- Strategies to ensure fairness among waiting orders/customers and prevent race conditions.
Assumptions
- The simulation operates within a single process with shared memory.
- No networking or distributed system concerns are required.