A group of participants cannot proceed because each waits for a resource whose release depends on another participant in the group. Consider two initially free mutex objects A and B. T1 acquires A then tries B; T2 acquires B then tries A. If each obtains its first mutex, both wait permanently for the other, with release reachable only after the second acquisition. Each mutex still enforces mutual exclusion.[ref]
Figure 1.
Reachable states for opposite mutex acquisition orders and for one shared lock ordering
. Details.
Each software thread performs four indivisible operations: acquire its first mutex, acquire its second, release the second, release the first. An unavailable acquisition blocks; neither participant releases early. A state records each participant's completed-operation count and both owners. Exhaustive exploration finds 19 reachable states with opposite orders, including exactly one nonterminal state with no enabled operation: both counts are , T1 owns A, and T2 owns B. Giving both participants the order A then B leaves 16 reachable states and no such blocked state. Unshown grid positions are unreachable. These are tiny sequential consistency models, without timeouts, cancellation, recursive acquisition or other resources.
Absence of a reachable deadlock. In the finite acquisition model under deadlock, reaching a nonterminal state with no enabled operation is a finite witness to failure, so this formulation is a safety property. Sometimes the phrase is used for eventual acquisition by some requester, a liveness property; the intended requirement must be stated. Neither formulation by itself promises starvation freedom for every requester.
A shared order governing acquisition of distinct mutex objects. To prevent circular waiting, choose a strict total order and acquire only a higher-ranked mutex while retaining lower-ranked ones. In the two-object deadlock example, every participant acquires A before B. An outline of the argument is that ranks would strictly increase around any alleged waiting cycle, yet return to the starting rank, a contradiction. The rule must include acquisitions hidden inside called routines. It excludes this kind of deadlock, not arbitrary waiting on other resources or failure to schedule an owner.[ref]

Articles by others on the same topic (1)

A deadlock is a situation in computing where two or more processes cannot proceed because each is waiting for the other to release a resource. This results in a standstill where none of the involved processes can continue executing. Deadlocks commonly occur in systems that manage shared resources, such as databases, operating systems, and multithreaded applications. ### Key Characteristics of Deadlocks: 1. **Mutual Exclusion**: Resources cannot be shared; they are allotted exclusively to a process.