LEARN. PRACTICE. GROW.What was actually executed
The lab starts separate Python workers and creates an invented state file and a lock file in a private temporary directory. The first worker acquires LOCK_EX with LOCK_NB. A second tries the same object and ends with code 75 when it encounters contention. This code is an application choice; it is not an operational priority and does not prove a queue exists. The first owner remains alive and can write. The groups passed twice on CPython 3.13.1, Darwin arm64. Python documentation describes the Unix interface; the inspected Apple manuals are archived. Separate the historical reference from the result observed on this system without generalizing to a cluster or remote filesystem.
Exclusive access does not renew the plan
State starts at revision 7. A confirms that revision and writes change-a at revision 8. After A exits, B acquires the lock, but its request still expects 7: the worker returns stale and retains the existing value. The script resubmits an explicitly reassessed decision for 8 and writes change-b at revision 9. Repeating the request based on 8 is rejected again. In a fictional middleware change, an intervention during the wait can alter dependencies or configuration. Merely changing the expected number is insufficient. Inspect the difference, confirm the intended effect and obtain the decision required by the applicable process. The lab models a simple revision; it authenticates no approvers and implements no authorization workflow.
The boundary of cooperation
With B still active and holding the lock, the script starts another process that directly writes revision 10 with outside-protocol. That process does not request the lock. B’s next read finds 10 and rejects an operation based on 9. The exercise shows detection of the change deliberately completed before the read, but also shows the advisory lock did not prevent the outside writer. In an APS tool, inventory automation, administrative consoles, old scripts and emergency paths. All relevant writers need a coherent control or another suitable protection. Choosing a lock file per project can also leave two projects uncoordinated when changing the same resource; scope must correspond to the state actually shared.
The window continues running during the wait
Acquiring a resource resolves only one execution condition. If eight minutes remain and the plan requires ten for application, six for validation and eight for recovery, the sequence no longer fits the window. Do not use successful acquisition to justify automatic startup or consume recovery reserve without a valid decision. Revisit dependencies, available people, current state and authority for the impact period. In a fictional committee, communicate the reason for waiting, usable time and options for rescheduling or extension. The lock has a limited technical role; it does not replace coordination with the service owner. These example timings are invented for decision practice, not a bank SLA or standard.
python3 content/labs/change-coordination/run.py --output /tmp/dr-change-coordination.json
# Observe secondOwnerRejected and acquisitionDoesNotRefreshPlan.
# Use only the private disposable resources created by the lab.A writes revision 8; B subsequently acquires the lock, but the request prepared for revision 7 is rejected without writing.
Common pitfalls
Treating acquisition as authorization, changing expectedRevision merely to pass or assuming a lock stops every writer.
Related topics: Windows and dependencies · Resource identity and recovery
The control covers only participants sharing the same object; gaining access does not automatically renew plan assumptions.
Reference: Archived Mac OS X manual: flock(2) · BigSavant Change Management 2026.1; independent technical curriculum