Multi-Barber Shop

Simulates a barbershop with two barbers where customers prefer one barber over the other but will accept either.

Problem

Two barbers share a waiting room. Customers arrive with interarrival times uniform(18, 6) minutes. Each customer prefers Barber 1 but will take Barber 2 if Barber 1 is busy and Barber 2 is free. If both are busy, the customer waits in a common FIFO queue. Service time is uniform(16, 4) minutes per barber.

This is an extension of the single-barber shop, specifically designed to demonstrate "Transfer Both" semantics and shared queue management.

Model in this directory

The model implements a dual-resource system with a shared waiting area:

Customer puck (lines 42-104): Represents the client. Upon arrival, the puck attempts to "fast-path" into Barber 1, then Barber 2. If both are occupied, it joins the wait_list and suspends.
Shop struct (lines 25-40): Holds the state for both barber1 and barber2 (represented as sim.Facility), a sim.Set for the common queue, and statistics trackers.
dispatch procedure (lines 125-153): A coordinator function called by either barber upon completing a service. It checks for available barbers and reactivates the next customer from the shared queue.

Why this shape

The "Transfer Both" logic is explicitly coded in the Customer.Arriving state (lines 55-65). By checking the .busy flag of each facility in a specific order before suspending, the model ensures that Barber 1 always gets priority for new arrivals.

The use of a separate sim.Set for the wait_list (instead of using the facilities' internal waiters) is critical. If customers waited in the facilities' internal queues, they would be locked to one barber. By using a shared set, any barber who becomes free can pull any customer from the head of the queue, maintaining a global FIFO discipline across the shop.

Alternatives considered

Internal Facility Queues: As noted, this would result in two separate queues, which does not match the real-world behavior of a single waiting room.
Dispatcher Puck: A separate puck could have been created to monitor both barbers and the queue. However, triggering the dispatch logic from the In_Service completion event is more efficient and avoids polling.

What this example teaches

Preferential Routing: Implementing "try A, then try B" fallback logic.
Global FIFO: Managing a shared queue for multiple heterogeneous resources to ensure fairness.
Resource Balancing: Analyzing how preference for one resource affects the utilization of others.

Running it

odin run examples/multi_barber

CLI

./multi_barber [options]

Add --json to emit the uniform envelope (metadata, execution_stats, metrics, details) instead of the default text output.

Flag	Type	Default	Description
`--json`	bool	`false`	Emit uniform JSON envelope instead of text.

Example runs:

./multi_barber           # default text run
./multi_barber --json    # uniform envelope

Multi-Barber Shop — README