Resource Acquisition Protocol¶
Protocol — instantiates Deadlock Prevention
Specifies how actors request, acquire, hold, and release resources so conflicting acquisition sequences cannot create circular blocking.
A Resource Acquisition Protocol is the umbrella contract that governs a resource's whole life in a participant's hands — how it is requested, how the grant is made, the obligations that come with holding it, and how and when it must be handed back. Where a lock ordering rule dictates the sequence across several resources and a lease bounds the duration of one hold, this protocol standardizes the lifecycle: it defines who may ask for what (an inventory of resources mapped to the actors allowed to hold them), what a well-formed request looks like, and — its distinguishing spine — the explicit release rule that says every acquired resource carries a defined obligation to relinquish it. By making acquisition and release a single disciplined transaction rather than ad-hoc grab-and-keep, it removes the loose holding behaviour that lets conflicting sequences accumulate into a circular wait.
Example¶
A warehouse runs a fleet of autonomous mobile robots (AGVs). Each pick job requires the robot to acquire three things in turn — the right to enter a particular aisle, a slot at a pick station, and time on a shared charging dock afterward. Early on, robots simply grabbed whatever they reached and held it: a robot that entered an aisle and then found the pick station busy would sit in the aisle indefinitely, blocking a second robot that held the pick station and was waiting to enter that aisle. The floor jammed with robots frozen against each other.
The fleet controller imposes a resource acquisition protocol. It publishes an inventory of contended resources (aisles, pick slots, docks) and a map of which robot classes may hold which. Every acquisition is now a structured request through the controller, and — the key clause — each grant comes with an explicit release obligation: a robot must relinquish an aisle if it cannot secure its next resource within the request, rather than parking in it. "Release before you block" becomes the rule of the floor. A robot that can't get the pick station gives up the aisle and re-requests the pair cleanly, so no robot holds an aisle hostage while waiting for a station. The jams stop, because holding is now always paired with a defined release.
How it works¶
- Publish the inventory and the actor map. The protocol names every contendable resource and the participants permitted to acquire and hold each — you cannot govern acquisition of things you have not enumerated or attributed to actors.
- Make requests structured, not ad-hoc. Acquisition goes through a defined request form (what, for how long, in what role) rather than an opportunistic grab, so the system can reason about who holds what.
- Attach a release obligation to every grant. Each acquired resource carries an explicit rule for when it must be released — including "release rather than block" — so a holder cannot passively sit on a resource while stuck.
- Make acquire-and-release one discipline. Holding is a bounded, accountable phase with a defined exit, not indefinite possession, which is what starves the hold-and-wait behaviour cycles feed on.
Tuning parameters¶
- Release-rule strictness — from "release only when done" to "release the moment you would otherwise block." Stricter release prevents more stalls but forces more re-request churn.
- Request granularity — one resource per request versus a declared multi-resource request. Coarser requests let the protocol coordinate the whole set; finer ones are simpler but see less of the actor's intent.
- Actor-map specificity — how tightly roles are bound to resources. Tight binding prevents unexpected contenders but is rigid when roles shift.
- Coordination locus — a central controller granting requests versus a published protocol each actor self-enforces. Central grants see everything but bottleneck; distributed enforcement scales but depends on every actor obeying.
When it helps, and when it misleads¶
Its strength is that it makes resource handling legible and accountable: because every acquisition is a structured request tied to a release obligation, the system always knows who holds what and every hold has a defined end — the lifecycle discipline that resource-management idioms like RAII enforce, where acquiring a resource inseparably binds its eventual release.[n1] It is the connective tissue other prevention mechanisms plug into.
Its failure mode is that a protocol is only as good as its observance and completeness: an actor that acquires outside the protocol, or a contended resource left off the inventory, reintroduces exactly the ad-hoc holding it was meant to remove — the classic misuse is a protocol that specifies request and acquire in detail but leaves release vague, so participants technically comply while still hoarding. It can also add ceremony and a coordination bottleneck that a simple, low-contention system does not need. The guarding discipline is to make the release rule as concrete as the acquire rule, to keep the resource inventory exhaustive, and to enforce that no participant acquires a contended resource outside the protocol.
How it implements the components¶
shared_resource_inventory— it publishes the catalog of contendable resources the protocol governs; requests are defined against it.actor_process_map— it maps which participants may request and hold each resource, attaching the rules to concrete actors.preemption_or_release_rule— it fixes the release side of the lifecycle: every hold carries a defined obligation to relinquish, including release-before-block.
It does not impose a global order across multiple resources (resource_acquisition_order_rule) — that is Lock Ordering Protocol; nor does it bound how long a single hold may last (timeout_or_lease_rule) — that is Lease-Based Resource Hold. This protocol governs the request-hold-release lifecycle; where it fixes the *release obligation, Preemption with Rollback handles the involuntary reclamation-with-repair side of the same component.*
Related¶
- Instantiates: Deadlock Prevention — it standardizes the acquire-hold-release lifecycle so ad-hoc holding cannot compound into a cycle.
- Sibling mechanisms: Lock Ordering Protocol · Lease-Based Resource Hold · All-or-Nothing Acquisition · Preemption with Rollback · Try-Lock and Backoff · Reservation and Capacity Escrow
Editorial Notes¶
Form Classification¶
Form family: Protocol, Workflow & Routine
Rationale: Resource Acquisition Protocol operates as a repeatable ordered procedure or handoff sequence that coordinates action because it specifies how actors request, acquire, hold, and release resources so conflicting acquisition sequences cannot create circular blocking.
Independent corroboration: The frozen evidence defines Resource Acquisition Protocol as 'Specifies how actors request, acquire, hold, and release resources so conflicting acquisition sequences cannot create circular blocking', so its operative form is Protocol, Workflow & Routine.
Nearest alternative: Rule, Policy & Commitment — Resource Acquisition Protocol includes features of a standing rule, threshold, contractual commitment, or policy constraint governing future conduct, but its defining operation is a repeatable ordered procedure or handoff sequence that coordinates action.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Multi-domain
Rationale: Ordered resource acquisition and release to prevent circular wait is a canonical operating-systems concurrency practice.
Related originating lineages:
- Operations Research — Resource scheduling and deadlock analysis materially formalized competing allocations.
Review resolution: Both blind reviewers agree that computer_science is the primary historical origin. Explicit reconciliation of alternate origin disagreement, domain reach disagreement adopts reviewer_a's evidence: Ordered resource acquisition and release to prevent circular wait is a canonical operating-systems concurrency practice. The selected record uses alternates=operations_research, origin_mode=single_lineage, and domain_reach=multi_domain; the other review proposed alternates=engineering_design, origin_mode=single_lineage, and domain_reach=specialized. The selected combination better preserves the mechanism-specific formative lineages and calibrated scope; broader present-day use is not treated as proof of additional historical origin.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] RAII (Resource Acquisition Is Initialization), the C++ idiom due to Bjarne Stroustrup, binds a resource's lifetime to a scope so that acquiring it also guarantees its release when the scope exits. It captures the core discipline of an acquisition protocol: a resource is never simply grabbed and held; acquisition and release are two ends of one accountable transaction. ↩