{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

{{ badge.label }} {{ badge.value }}
Test the current state or evaluate one process request without mutating a rejected base state.
Load a bounded example, then inspect or edit every value before tracing it.
Use 1–4 unique names and whole totals from 0 to 99.
ResourceTotal unitsRemove
Each resource pair is Allocation / Max. Allocation cannot exceed Max or the resource total.
Process{{ resource.id || 'Resource' }}Allocation / MaxRemove
{{ playback_interval }} ms
The neutral default is 700 ms. Step always advances exactly one canonical frame.

{{ workflow_mode === 'request' ? 'Resource request algorithm' : 'Safety algorithm' }}

{{ currentFrame.title }}

{{ currentFrame.message }}

Step {{ currentFrameIndex + 1 }}of {{ traceFrames.length }}
Available{{ vectorDisplay(currentFrame.available) }}
Work{{ vectorDisplay(currentFrame.work) }}
Finish{{ currentFrame.finish.map(finishLabel).join(', ') || '—' }}
Sequence{{ currentFrame.sequence.join(' → ') || 'None yet' }}

{{ workflowMessage }}

ProcessAllocationMaxNeedOutcomeCopy
{{ row.id }}{{ vectorDisplay(row.allocation) }}{{ vectorDisplay(row.max) }}{{ vectorDisplay(row.need) }}{{ row.outcome }}
Process Synchronization Simulator Trace producer-consumer and dining synchronization with repeatable mutex and semaphore evidence for blocking, wakeups, progress and deadlock.
CPU Scheduling Algorithm Simulator Compare CPU scheduling policies through dispatch traces and ready-queue decisions, including context-switch overhead and per-process timing metrics.
Memory Allocation Algorithm Simulator Compare contiguous memory fit policies through stepwise placements, coalescing and failure reasons alongside external fragmentation 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.

A system can have enough resources in total and still reach a point where no process can finish. The danger comes from partial allocations: each process holds some units while retaining the right to ask for more. If every unfinished process waits for units held by another, progress stops.

Banker’s algorithm avoids that situation by admitting only states with a safe completion order. A safe sequence is a witness that every process could receive its remaining maximum claim, finish, and release what it holds. The sequence is a planning guarantee under the declared claims, not a prediction of the order in which processes will actually run.

Allocation
Units currently held by a process.
Maximum claim
The most units that process may need at one time.
Need
The unfulfilled part of the maximum claim.
Available
Units not currently allocated to any process.

A state is unsafe when no safe sequence can be demonstrated. Unsafe does not mean that a deadlock already exists; it means future requests could produce one, so the declared completion guarantee has been lost. A request may also have to wait simply because too few units are available now, even though the underlying state remains safe.

The method depends on truthful, fixed maximum claims and interchangeable units within each resource type. It is less suitable when resource needs are unknown, claims change during execution, resources cannot be counted as identical units, or recovery after deadlock is preferred to conservative admission.

How to Use This Tool:

Build one bounded resource model, then either test its current safety or evaluate a single request without changing a rejected base state.

  1. Choose Safety test to inspect the current model, or Resource request to test a tentative allocation.
  2. Define 1 to 4 resource types and 1 to 6 processes. Use unique names and whole-number totals from 0 to 99.
  3. Enter each process’s Allocation / Max pair for every resource. Allocation must not exceed Max, Max must not exceed the resource total, and all allocations together must fit the total.
  4. For a resource request, select the requesting process and enter one amount per resource type. The request must fit both that process’s remaining Need and the current Available vector before the tentative safety test can begin.
  5. Start the trace and step through changes to Work, Finish, and the safe-sequence witness. Correct the first reported input issue when the trace cannot start.

Interpreting Results:

  • Safe state supplies a complete witness sequence. Other valid safe sequences may exist.
  • Unsafe state means the declared claims cannot all be guaranteed from the current allocation; it is not proof that processes are already deadlocked.
  • Request granted means the tentative allocation remains safe and can be committed.
  • Request waiting means the request is within the process’s Need but exceeds Available now. No allocation changes.
  • Request invalid means at least one requested amount exceeds the process’s remaining Need.
  • Request rolled back means the request fit Need and Available but made the tentative state unsafe, so the original model remains current.

Technical Details:

Every resource quantity is a vector component. Comparisons are component-wise, so a process is eligible only when its remaining Need fits Work for every resource type at once.

Formula Core:

Need subtracts the current allocation from the declared maximum, while Available subtracts all current allocations from the system total.

Needi = Maxi−Allocationi Available = Total−∑i=1nAllocationi

All terms are integer vectors with one component per resource type. No rounding occurs.

Rule Core:

Stage Rule Consequence
Initialize Set Work to Available and mark every process unfinished. The trace begins with only currently unallocated units.
Select Choose the first unfinished process in stable row order whose Need is less than or equal to Work in every component. That process can be guaranteed enough units to finish.
Release Add the selected process’s Allocation to Work and mark it finished. Released units may make another process eligible.
Conclude All processes finished means safe; no eligible unfinished process means unsafe. The completed order is the safe-sequence witness.
Test a request Require Request ≤ Need and Request ≤ Available, apply it tentatively, then run the safety test. Commit only a safe tentative state; otherwise wait, reject, or roll back without mutating the base state.

Worked Examples:

A grant that remains safe

Suppose resource A has 3 units and P0 currently holds 1 with a maximum claim of 2. Available is 2 and P0’s Need is 1. A request for 1 unit fits both limits; after the tentative grant, P0 can finish and release its 2 units, so the request is granted with P0 as the witness sequence.

References: