Resource Acquisition/Release Stack¶
Resource cleanup protocol — instantiates LIFO Stack Discipline
Records each acquired resource as it is taken and guarantees release in strict reverse order — even when work fails partway — so no dependent resource is ever freed before the thing that relied on it.
The Resource Acquisition/Release Stack protects cleanup order. Whenever a piece of work takes hold of something that must later be given back — a lock, a file handle, a network connection, a temporary elevation of privilege — the acquisition is recorded on a stack of pending release obligations. When the work finishes, obligations are discharged in reverse of the order they were incurred: last acquired, first released. Its defining commitment, the one that separates it from a mere sequence of close() calls, is that release is guaranteed even on failure: if the work throws or is cancelled with three resources held, the protocol still walks the stack top-down and releases all three. It manages release obligations, not stored state — it does not remember what the resource contained, only that it is owed back, and in what order.
Example¶
A crew erects scaffolding up the face of a building. They build from the ground: base standards and the first platform go up (acquired first), then a second lift is clamped on top of that, then a third lift on top of the second. Each level physically rests on the one below — the third lift depends on the second remaining in place. When the job ends, dismantling must run in reverse: top lift first, then the second, then the base. Pulling the base out while upper lifts still stand would drop everything. That reverse-order rule is the release stack made of steel.
Now the failure case that makes the protocol earn its keep: a storm forces an emergency stop with all three lifts up. The crew does not improvise or leave a half-secured level hanging. They unwind the same way — top lift down first, then the next — because the dependency order that governed safe erection still governs safe teardown under duress. The stack of "what we put up, in order" is exactly the checklist for "what to take down, and in which order," normal exit or emergency alike.
How it works¶
The protocol wraps each acquisition so the matching release is registered the instant the resource is taken:
- On acquire: obtain the resource and push its release action (the "undo" for having it, not for what it holds) onto the obligation stack. Acquisition and registration are inseparable — you cannot hold a resource that isn't on the stack.
- On normal exit: pop and run each release from the top down, so a resource is freed only after everything acquired later (and possibly depending on it) is already released.
- On abnormal exit: the same top-down walk runs during unwinding, so a throw with N resources held still releases all N in reverse. This is the part improvised cleanup gets wrong.
- Idempotence: each release is marked done when run, so a resource is never released twice even if both a normal and an exceptional path reach it.
Tuning parameters¶
- Registration coupling — how tightly acquire and release-registration are bound (a scope-based
with/defer/RAII construct binds them at the language level; a manual list leaves a gap where a resource can be held but unregistered). Tighter coupling is safer; looser gives finer control. - Release failure policy — if a release itself fails mid-unwind, whether to continue releasing the rest (usually yes — keep unwinding) or abort. Continuing prevents one stuck handle from leaking all the others.
- Grouping granularity — one obligation per resource, or a batched compound release. Fine grouping gives exact reverse order; batching is simpler but can release co-dependent resources in the wrong internal order.
- Timeout on release — how long to wait for a slow release (flushing a buffer, closing a socket) before forcing it. Bounds unwind time at the risk of a not-fully-clean release.
When it helps, and when it misleads¶
Its strength is exception safety: cleanup that is correct by construction on every exit path, normal or not, which is exactly what hand-written close() calls scattered through error branches fail to deliver.[n1] It also makes acquisition order the single source of truth for teardown order, so dependent resources are never freed out from under their dependents.
Its failure mode appears when the release order the stack enforces is not the order actually required — most often when two held resources have a dependency that doesn't match acquisition order, or when a release has genuine side effects that themselves can fail. The classic misuse is acquiring resources in an order chosen for convenience rather than for safe teardown, so strict-reverse release ends up freeing something still in use. The guarding discipline is to acquire in dependency order deliberately (so reverse release is automatically safe) and to make each release tolerant of being run during a failure it didn't cause. Note that this protocol frees resources; it does not roll back the data changes a failed operation made — that is a different mechanism.
How it implements the components¶
push_admission_rule— acquiring a resource is the admission event; the release obligation is pushed at the moment of acquisition, so nothing is held off-stack.pop_or_unwind_rule— releases run strictly top-down, the reverse of acquisition, on every exit path.exception_unwind_policy— an error or cancellation triggers the same reverse-order release walk rather than improvised, order-blind cleanup; this is the component the mechanism exists to guarantee.restoration_invariant— a resource counts as released only when the enclosing context's precondition is restored (lock free, handle closed, privilege lowered), so the parent scope resumes exactly as it was.
It does not implement frame_payload_and_local_state — snapshotting the tentative *state a scope produced, so it can be rewound to a marker, is the job of Transaction Savepoint Stack, its nearest twin; nor frame_type_registry, the kind-matching used by Parser Delimiter Stack. The difference from the savepoint stack in one line: this protocol releases acquired resources in reverse order, whereas the savepoint stack rewinds stored data back to a marker — one frees, the other un-does.*
Related¶
- Instantiates: LIFO Stack Discipline — reverse-order cleanup is the archetype applied to resource ownership.
- Consumes: Push/Pop Interface — the obligation list is a LIFO stack of pending releases.
- Sibling mechanisms: Call Stack and Activation Records · Push/Pop Interface · Parser Delimiter Stack · Transaction Savepoint Stack · Undo/Redo Stack Pair · Breadcrumb Navigation Stack · Depth Limit and Stack Trace
Editorial Notes¶
Form Classification¶
Form family: Protocol, Workflow & Routine
Rationale: Resource Acquisition/Release Stack operates as a repeatable ordered procedure or handoff sequence that coordinates action because it records each acquired resource as it is taken and guarantees release in strict reverse order — even when work fails partway — so no dependent resource is ever freed before the thing that relied on it.
Independent corroboration: The frozen evidence defines Resource Acquisition/Release Stack as 'Records each acquired resource as it is taken and guarantees release in strict reverse order — even when work fails partway — so no dependent resource is ever freed before the thing that relied on it', so its operative form is Protocol, Workflow & Routine.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Stack-disciplined reverse-order resource release under failure is a software resource-management pattern.
Review resolution: Both blind reviewers agree that computer_science is the primary historical origin. Explicit reconciliation of alternate origin disagreement adopts reviewer_a's evidence: Stack-disciplined reverse-order resource release under failure is a software resource-management pattern. The selected record uses alternates=none, origin_mode=single_lineage, and domain_reach=specialized; 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] Resource Acquisition Is Initialization (RAII), the C++ idiom, ties a resource's lifetime to a scoped object so its destructor releases the resource automatically when the scope exits — normally or via an exception. try…finally, with, using, and defer in other languages serve the same guaranteed-release purpose. ↩