Concurrent Session Safety: Resource Locks

Everything on the previous four pages describes one loop acting alone. In practice, more than one session or loop can be working against the same shared repository at the same time — and without a real mutual-exclusion mechanism, two of them can collide: one loop's in-progress change getting silently carried onto another loop's branch, or a repo-wide check picking up another session's uncommitted work as if it belonged to the current one. This has actually happened here, not just as a hypothetical risk.

What the lock actually guards

Before any action that mutates the shared repository or triggers a deployment, a loop acquires a named lock scoped to that resource (the working directory itself, or a specific deploy target) rather than proceeding directly. If no other loop holds it, acquisition is immediate — a solo run never pays a tax for a lock nobody else is contending for. If another loop already holds it, the requester waits with backoff instead of one of the two worse alternatives: proceeding anyway and risking a collision, or failing outright and losing the work.

This covers loops that go through the mechanism that acquires it — it is not a blanket guarantee over every git operation anyone might run by hand. An ad hoc command typed directly into a shared session doesn't automatically pass through the lock just because a lock exists; the safety comes from the loop's own code path acquiring it, not from the working directory itself somehow being protected.

Why atomic acquisition, specifically

A naive version of this check — read whether the lock is held, then write that you're taking it — has a real race condition: two loops can both read "not held" before either one writes "held," and both proceed as if they have exclusive access. The actual mechanism uses an atomic exclusive-create operation instead, so two simultaneous requests can never both believe they hold the same lock.

What happens if the holder disappears

A lock is only useful if it can't outlive the thing that took it. If the holder crashes or is killed without releasing it, a stale lock that nothing ever clears would block every future attempt indefinitely — the same failure mode a stale deploy lock produces (see the quality gates and approval gates this guard sits alongside). The mechanism verifies liveness rather than trusting that a lock file's mere existence means the work is still in progress.

This is not the same thing as an approval gate

An approval gate answers "is a human willing to let this happen." A resource lock answers "is it safe for this to happen right now, given what else might be running." Both can apply to the same action — a commit can need a human's approval and exclusive access to the working directory — and neither one substitutes for the other.

The SDLC, Paper 4: Concurrent Loops is where "this has actually happened here" gets its date and its full incident narrative — two independent collisions in one working directory, and what changed after.