Distinguish a circular resource wait from an ordinary backlog

Define the progress question

Oracle’s JDK 8 tutorial describes threads blocked waiting for one another. Use that conceptual distinction, not its historical code, to frame this synthetic exercise.

Start with one clearly bounded automated operation. State what completion would mean and ask what evidence shows that the operation can still reach it. A dashboard saying busy or pending may describe an interface state without explaining the underlying obstacle. Preserve the observed state instead of assuming that a familiar status label implies ordinary processing.

Keep the diagnosis separate from a proposed remedy. Adding equipment, restarting a service or canceling a job can have consequences outside the immediate symptom. The exercise below makes no such change. It gives the qualified implementation owner a specific question to investigate rather than inviting a production coordinator to improvise a recovery action.

Trace the retained resources

The model has two unique tokens, X and Y. A requests X then Y; B requests Y then X. A can hold X while B holds Y. Each next request is unavailable; completion requires both tokens, and release occurs only at completion. Neither job has an enabled transition.

UIC’s secondary notes distinguish the single-instance cycle criterion from multiple-instance cases. Retain that limit; a cycle alone is not a general diagnostic for arbitrary resource pools.

Write the owner and next request beside each token. The explanation must identify what is preventing the next action, not simply repeat that the jobs are stuck. If a real system can release, cancel or time out through another route, that route must be represented before applying this model’s conclusion. Do not erase a valid recovery path to make the production incident resemble the teaching example.

Compare the trace with the original accepted job definitions. If the supposed requirement is only an assumption inferred from a screen, ask the implementation owner to verify it. The graph is useful because it exposes the claim that needs evidence; drawing an arrow does not prove that the real process follows it.

Explore every modeled continuation

Represent each job’s progress as 0: nothing held, 1: first token held, 2: both held, 3: complete and released. Explore every enabled acquisition or completion. Opposite orders yield 13 reachable states, with unfinished terminal (1,1). With both jobs requesting X then Y, 12 states are reachable and every terminal is (3,3).

Oracle’s Solaris guide explains consistent acquisition ordering. Our exhaustive check covers this finite token model only: each transition advances a job, with no stuttering or infinite scheduler refusal. It proves neither elapsed waiting time nor fairness in a real system.

Preserve the reachable-state list and all transition edges, not just the final counts. Counts alone would not reveal which situation caused the obstruction. A reviewer should reconstruct one failing path and one successful path, then inspect how the alternative changes the available next action. That comparison is more informative than saying that the revised process passed a test.

The execution uses an abstract state explorer, not actual blocked threads. This is a deliberate evidence boundary. It avoids creating a live failure while leaving the stated model completely inspectable. A production implementation still needs its own qualified review before any proposed change can be accepted.

Report the cause without prescribing an unsafe recovery

Prepare a short incident question containing the observed symptom, proposed resource interpretation and missing implementation evidence. Avoid assigning blame to the last job that appeared on the dashboard. The stopping pattern concerns an interaction between requests; the visible order of status updates is not automatically the causal sequence.

If the owner confirms a different mechanism, keep that correction with the original hypothesis. A slow external dependency, an unavailable input and an internal progress obstruction call for different investigations. Treating all of them as a capacity shortage can produce expensive changes without answering the actual question.

Conclude with the bounded finding and the person who can evaluate it operationally. Do not terminate work, release retained resources or modify permissions as part of this lesson. The deliverable is a precise explanation of the modeled obstruction and a reviewable alternative, not a promise that a production system is deadlock-free or that every waiting job will finish promptly.

Make the reasoning concrete.

A fictional asset pipeline has two accepted jobs that never reach its completion screen. The coordinator considers whether to request more processing capacity before understanding the state evidence.

The coordinator sends an internal review question without changing the pipeline or stopping work.

Take the questions into your next brief.

Use these prompts in your own notes. Nothing is submitted from this page.

1. Completion

   What actual event would establish that the operation finished?

2. Evidence

   Which observed facts support the proposed resource interpretation?

3. Trace

   Can the failing path be reconstructed from explicit states?

4. Alternative

   What does the bounded comparison establish and leave open?

5. Owner

   Who can verify the real implementation safely?

Watch for the wrong conclusion.

• Inferring a cause from an unchanged dashboard.
• Treating an illustrative graph as production evidence.
• Attempting a recovery action without qualified authorization.

Sources & scope

Original fictional inputs, local calculations and operational interpretation. Sources support identified mechanisms and their applications. No operational change, commercial commitment or personnel decision is made.

• Deadlock →Primary vendor teaching documentation · Supports: Supports the conceptual distinction.
• Deadlocks →Secondary university course notes · Supports: Supports the single-instance limitation.
• Avoiding Deadlock →Primary vendor documentation · Supports: Supports consistent acquisition ordering; March 2019 Solaris guide.