All-or-Nothing Acquisition¶
Procedure — instantiates Deadlock Prevention
Prevents hold-and-wait by requiring a process or actor to acquire all needed resources before proceeding, or release everything and retry later.
All-or-Nothing Acquisition attacks deadlock at exactly one of its four preconditions: hold-and-wait, the state in which a participant clutches something it already has while blocking on something it still needs.[1] The rule is blunt and total — you may not begin until you hold the entire bundle of resources your task requires, and if you cannot get all of them at once, you take none of them and retry the whole request later. Because no participant ever sits on a partial set while waiting for the rest, the "holds one, waits for another" link that every circular wait is built from can never appear. Its defining idea is atomic acquisition of the whole set: there is no such thing as a partial hold to be trapped in.
Example¶
A film production needs four things to shoot a single complex scene: a specific sound stage, the two lead actors (both booked across other productions), a specialized camera rig, and a licensed pyrotechnics crew. Booked separately, the schedule keeps deadlocking — the stage is reserved for a week during which one lead is available but the rig is out; by the time the rig frees up, the pyrotechnics crew has been committed elsewhere and the stage is gone. Each partial booking is locally sensible and collectively fatal; every held reservation is a hostage.
The line producer switches to all-or-nothing. A scene is not put on the calendar until a single coordinated request confirms all four resources for the same window, drawn from a maintained inventory of what each requires. If any one is unavailable, nothing is reserved — the stage is released back to the pool immediately rather than held "just in case," and the request re-enters the queue for the next window when the full set can be assembled. A small buffer of hold-days is kept so the four confirmations do not have to land in the same instant. Bookings drop, but the productions stop stranding each other on half-assembled shoots.
How it works¶
- Enumerate the whole bundle up front. The task must declare every resource it needs before acquiring any, which requires a maintained inventory of what each job consumes — the mechanism cannot acquire atomically what it has not listed.
- Acquire all or acquire none. A single coordinated claim either secures the entire set or fails cleanly, releasing anything provisionally taken; a partial success is treated as a failure.
- Release fully and retry. On failure the actor drops everything — it does not linger holding the pieces it did get — and re-requests the complete set later, optionally through a buffer that absorbs small timing gaps so the confirmations need not be simultaneous to the millisecond.
Tuning parameters¶
- Bundle scope — how tightly the required set is drawn. Over-declaring resources you might need makes acquisition rarer and starves others; under-declaring reintroduces mid-task waiting.
- Retry cadence — how soon a failed request tries again, and with what spacing. Aggressive retries waste effort re-assembling doomed bundles; slow ones stall throughput.
- Buffer / escrow depth — how much slack capacity is held so confirmations needn't be instantaneous. Deeper buffers raise success rates but tie up resources that could serve others.
- Fairness guard — whether small requests can perpetually leapfrog a large bundle that never assembles. Without one, big all-or-nothing jobs can starve indefinitely.
When it helps, and when it misleads¶
Its strength is completeness and simplicity: by making partial holds impossible it removes hold-and-wait outright, and it is easy to reason about — a task is either fully provisioned and running or not started at all. Where the required set is small and knowable, it is often the cleanest prevention there is.
Its failure mode is poor utilization and starvation. Requiring the whole bundle before starting means resources sit idle whenever the set is large or slow to assemble, and a job that needs many scarce things may never win them all at the same instant while smaller jobs keep slipping through — the classic misuse is applying it to a big, uncertain resource set, where it converts a rare deadlock into chronic low throughput and indefinite postponement. It also demands that the full need be known in advance, which is exactly what an exploratory task cannot supply. The guarding discipline is to keep bundles minimal and well-inventoried, to add a fairness guard so large requests eventually get a protected turn, and to reach for a different mechanism when needs are discovered mid-task rather than declarable up front.
How it implements the components¶
hold_and_wait_limit— this is its whole reason for being: by forbidding a start on any partial set, it eliminates the hold-and-wait condition directly.shared_resource_inventory— atomic acquisition forces an explicit, maintained list of everything a task requires, since you cannot claim as a bundle what you have not enumerated.resource_pooling_or_buffer— a slack buffer lets the all-or-nothing claim succeed without demanding that every confirmation arrive in the same instant.
It does not impose a global sequence on how resources are taken (resource_acquisition_order_rule) — that is Lock Ordering Protocol; nor does it ever revoke a resource already granted to another (preemption_or_release_rule) — that is Preemption with Rollback. All-or-nothing prevents the partial hold rather than ordering or reclaiming holds.
Related¶
- Instantiates: Deadlock Prevention — it removes the hold-and-wait precondition of a circular wait.
- Sibling mechanisms: Reservation and Capacity Escrow (reserves linked resources but allows conditional partial holds) · Preemption with Rollback · Try-Lock and Backoff · Agenda Ordering Rule · Lock Ordering Protocol · Resource Acquisition Protocol
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: At runtime the mechanism atomically grants an entire declared resource bundle or fails cleanly and releases provisional claims, preventing partial holds, so its operative form is concurrency control.
Nearest alternative: Protocol, Workflow & Routine — Declaration, acquisition, and retry can be described as steps, but atomic enforcement over live resource state is what prevents hold-and-wait.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Multi-domain
Rationale: Operating-systems deadlock theory formalized the Coffman hold-and-wait condition and prevention by atomically requesting all required resources or releasing the partial set.
Related originating lineages:
- Operations Research — Scheduling and resource-allocation theory addresses bundle feasibility, retry, utilization, and starvation under scarce pooled resources.
- Organizational & Management Science — Project and production coordination transfer atomic booking to people, facilities, equipment, and approval bundles.
Review resolution: The acquire-all-or-release rule is a direct computer-science deadlock-avoidance mechanism. Operations research materially informs resource allocation and organizational practice supplies human scheduling applications, while the lineage remains single and multi-domain.
Review outcome: Reconciled after independent review; high confidence.
References¶
[1] The Coffman conditions (Coffman, Elphick & Shoshani, 1971) state the four properties that must all hold for deadlock to be possible: mutual exclusion, hold-and-wait, no preemption, and circular wait. Breaking any one prevents deadlock; all-or-nothing acquisition targets hold-and-wait specifically. withdrawn registry ↩