{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

Scenario {{ resultsReady ? simulation.scenarioLabel : '—' }} Blocked {{ resultsReady ? simulation.blockedCount : '—' }} Wait alert Active
Each option runs a fixed logical schedule, so the same inputs always produce the same trace.
slots
Use 1–5 slots. The trace reserves an empty permit before producing and a full permit before consuming.
actors
Use 3–5 philosophers and the same number of forks.
{{ resultsReady ? `${selectedStep + 1} / ${stepCount}` : '—' }}
Step 1 initializes the scenario; later steps reveal acquisition, blocking, wakeup, critical-section, release, and outcome decisions.
actors
The neutral default is 0, which disables the annotation. Use 1–5 to highlight crowded waits.
{{ frame.title }}

{{ frame.message }}

Active actor{{ frame.active_actor || 'Scheduler' }}
Transition{{ frame.active_action }}
Critical section{{ frame.critical_occupancy.length ? frame.critical_occupancy.join(', ') : 'Empty' }}
Outcome{{ decisionLabel }}
Actors
  • {{ actor.id }}{{ actor.state }}{{ actor.holds.length ? `Holds ${actor.holds.join(', ')}` : (actor.waiting_for ? `Waits for ${actor.waiting_for}` : 'No held resource') }}
Primitives
  • {{ primitive.id }}{{ primitive.kind }}{{ primitiveSummary(primitive) }}
{{ frame.decision === 'deadlocked' ? 'Circular-wait witness' : 'Current wait edges' }}{{ waitEdgeText }}
Progress reading: {{ simulation.interpretation }}

The chart renderer is unavailable. The same transition values remain available in the ledger.

StepTransitionActorBlockedDecisionExplanationCopy
{{ row.step }}{{ row.transition }}{{ row.actor }}{{ row.blocked }}{{ decisionDisplay(row.decision) }}{{ row.message }}
Banker's Algorithm Deadlock Avoidance Simulator Test Banker’s algorithm states and resource requests with step-by-step safety traces, safe-sequence witnesses, and rollback decisions.
CPU Scheduling Algorithm Simulator Compare CPU scheduling policies through dispatch traces and ready-queue decisions, including context-switch overhead and per-process timing metrics.
Page Replacement Algorithm Simulator Compare four page-replacement policies with step-by-step frame traces and see how fault counts, hit ratios and frame capacity change.
Memory Allocation Algorithm Simulator Compare contiguous memory fit policies through stepwise placements, coalescing and failure reasons alongside external fragmentation metrics.

Concurrent processes can interleave at almost any instruction. When more than one actor reads or changes shared state, the outcome depends on which operations are allowed to overlap and which actor must wait. Synchronization supplies those rules so a critical section has controlled access and shared counts stay consistent.

A mutex represents exclusive ownership. One actor can hold it, while another requester blocks until ownership is released. A counting semaphore represents a non-negative number of permits. A wait consumes a permit when one is available; otherwise the actor blocks. A signal either increases the available count or wakes a queued actor.

Situation Shared constraint Main question
Producer–consumerA bounded buffer has a mutex plus empty-slot and full-slot permits.Can a waiting consumer resume after a producer adds an item?
Dining deadlockEach philosopher needs two neighboring forks.Can every actor hold one resource while waiting forever for the next?
Ordered diningEvery philosopher requests the lower-numbered fork before the higher-numbered fork.Does one global order remove the circular-wait pattern?

Blocking is not automatically a failure. A process may wait briefly and then continue when a permit or mutex becomes available. Deadlock is stronger: the wait-for relationships form a closed cycle and no actor in that cycle can perform the release needed by another. Starvation is different again; an actor may remain postponed even though the system as a whole continues to make progress.

A deterministic teaching schedule makes each transition repeatable, which is useful for examining ownership, queues, and wakeups. It does not represent every scheduler interleaving, prove fairness, or establish that the same synchronization design is safe under all production workloads.

How to Use This Tool:

Choose the synchronization question first, then follow ownership and wait edges one transition at a time.

  1. Select Producer–consumer, Dining deadlock, or Ordered dining under Scenario.
  2. For producer–consumer, set Buffer capacity from 1 to 5 slots. For either dining scenario, set Philosophers from 3 to 5; the same number of forks is used.
  3. Move Trace step through the fixed schedule. Watch actor state, held resources, resource queues, critical-section occupancy, and wait edges change together.
  4. Set Blocked-actor alert from 1 to 5 when a crowded wait deserves emphasis, or leave it at 0 to disable the annotation. The alert highlights a count; it does not diagnose deadlock by itself.

Interpreting Results:

Start with the selected transition's ownership and wait edges. A blocked actor with an eventual wakeup is ordinary contention. A deadlocked final state has a closed actor-to-owner cycle and no enabled release. The critical-section count should never exceed one in these scenarios.

The blocking trend counts actors in the blocked state at each transition. A rising count shows contention building, but only the transition ledger and wait relationships explain why. Likewise, a completed bounded trace shows progress for that schedule, not fairness across an unlimited run.

The blocked-actor alert is a user-selected threshold. If the threshold is 2, it activates when the selected transition has 2 or more blocked actors. It is an annotation for inspection rather than a synchronization rule.

Technical Details:

Synchronization is modeled as a sequence of atomic state transitions. Each transition updates actors, primitives, shared state, critical-section occupancy, and wait edges before producing the next snapshot. Repeating the same scenario and counts therefore produces the same trace.

Mechanism Core:

Operation Success path Wait path Release or wake path
Mutex acquireAn unowned mutex becomes owned by the requester.The requester blocks and joins the mutex's FIFO queue.Release transfers ownership to the next queued actor, or leaves the mutex unowned.
Semaphore waitA positive permit count decreases by one.At zero, the requester blocks and joins the semaphore's FIFO queue.Signal transfers a permit to the next queued actor; without a waiter, it increases the available count.

Rule Core:

The three schedules combine those primitive operations in different orders.

Scenario Ordered rule path Terminal judgment
Producer–consumerThe consumer first waits on a zero full-slot semaphore. The producer reserves an empty slot, enters the mutex-protected section, adds one item, releases the mutex, and signals a full slot. FIFO wake hands that permit to the consumer, which removes the item and returns an empty-slot permit.Both actors complete with buffer 0, full permits 0, empty permits equal to capacity, and an unowned mutex.
Dining deadlockEvery philosopher acquires the left fork before any philosopher requests the right fork.Each actor holds one fork and waits for the next actor's fork, forming a closed cycle.
Ordered diningEvery philosopher requests the lower-numbered fork before the higher-numbered fork, enters once, exits, and releases both.All actors complete and every fork is unowned; the global order prevents this circular-wait pattern.

Blocked, held, and critical counts are direct counts from the selected snapshot. The alert rule is active only when its threshold is greater than 0 and the blocked count is greater than or equal to that threshold.

No Formula Core is used because the governing behavior is an ordered state-transition system rather than an equation. Counts summarize the current state; they do not calculate safety, fairness, or deadlock from a numeric score.

Limitations:

The schedules are bounded demonstrations with a declared FIFO wake policy. Real mutex and semaphore implementations, operating-system schedulers, language runtimes, and application protocols can make different fairness and wake-order guarantees.

  • Completion proves progress only for the displayed schedule.
  • Global fork ordering removes the demonstrated circular wait but does not by itself prove starvation freedom.
  • The simulator does not model memory ordering, condition variables, priority inversion, timeouts, cancellation, or failures inside a critical section.

References: