Atomic Check-and-Use Operation¶
Concurrency-control primitive — instantiates Use-Time Referent Validation
Fuses the validity check and the dependent action into one indivisible operation, so no other actor can change the referent in between — there is no window to lose a race in.
Every other guard in this family leaves a seam between confirming a referent and using it; Atomic Check-and-Use Operation removes the seam. It binds the validity check and the action that depends on it into a single indivisible operation — enforced by a lock, a transaction, a hardware compare-and-set, or a critical section — so that concurrent actors are serialized and no state change can occur between the check and the use. Its defining move is not to check late (that is the just-in-time existence check) or to detect a change after the fact (that is the version guard) but to make the interval itself not exist: the operation either happens wholly against a valid referent or not at all. The guarantee is bought with exclusivity — whatever sits inside the boundary is serialized, and that costs throughput.
Example¶
A flash sale has one unit of an item left, and two orders arrive in the same millisecond. A naive flow reads the count — 1 for both — decides "in stock" for both, then decrements for both, and the item is oversold to −1. An atomic check-and-use collapses that read-decide-write into one indivisible operation: a single compare-and-swap that decrements the counter from 1 to 0 only if it is still 1. The first order's operation succeeds and takes the unit; the second order's identical operation finds the counter is no longer 1 and fails cleanly, routing that buyer to "sold out." Exactly one unit ships, and there is no instant between reading the count and committing the decrement for the other to squeeze into.
How it works¶
- Draw one boundary around check and use. A serialization primitive — mutex, transaction, hardware CAS, critical section — makes the validity test and the dependent write a single unit that other actors cannot interleave.
- Serialize contenders. Concurrent operations on the referent are ordered so each sees a consistent state; losers block or fail rather than acting on a stale read.
- Commit or nothing. The action commits inside the same boundary as the check, so a passed check can never be followed by a use against a since-changed referent.
- Keep the boundary minimal. Only the invariant that must hold across check-and-use goes inside; everything else stays out to limit what is serialized.
Tuning parameters¶
- Boundary width — how much work sits inside the atomic section. Wider guarantees more but serializes more and throttles throughput.
- Primitive — hardware CAS, mutex, database transaction, or distributed lock. Each trades protection scope against latency and blast radius.
- Isolation strength — how strong the serialization guarantee (e.g. strict-serializable versus weaker). Stronger prevents subtler anomalies at higher cost.
- Contention handling — block-and-wait versus fail-fast for the losers. Sets whether a race produces waiting or errors.
- Scope — one referent versus several in one atomic step. Multi-referent atomicity is far costlier and pushes toward a full transactional guard.
When it helps, and when it misleads¶
Its strength is absolute for what it covers: it is the only guard that fully eliminates the check-to-use race on the protected referent, making the action linearizable — it appears to take effect at a single instant.[n1] Where correctness cannot tolerate even a narrow window — issuing a unique seat, decrementing the last unit of stock, electing a single leader — this is the mechanism that gives an ironclad guarantee.
Its costs are the price of exclusivity. A wide boundary serializes work and throttles the system; a held lock that outlives its holder stalls everyone behind it; and it protects only what is inside the boundary — anything the action depends on outside it is still racy. The classic misuse is stretching the atomic section to cover slow or external work — a network call, a human step — so throughput collapses or the lock is held far too long. The discipline is to keep the boundary as small as the invariant demands and no larger, and to push everything that need not be indivisible outside it.
How it implements the components¶
check_use_binding_boundary— it is the boundary: check and use are fused into one indivisible unit, which is the mechanism's entire identity.race_window_probe— it targets exactly the race window between validation and use and collapses it to zero, so no concurrent change can occupy it.
It guarantees indivisibility but does not resolve or observe the referent (action_referent_dependency, use_moment_observation_channel — Just-in-Time Existence Check) or match an expected version after the fact (identity_and_sameness_test — Compare-and-Swap or Version Guard); wrapping the same all-or-nothing guarantee around a multi-step transaction with rollback is Transactional Precondition Guard's job.
Related¶
- Instantiates: Use-Time Referent Validation — Atomic Check-and-Use Operation supplies the no-gap guarantee that check and use hit the same, valid referent.
- Sibling mechanisms: Compare-and-Swap or Version Guard · Just-in-Time Existence Check · Transactional Precondition Guard · Lease, Lock, or Reservation Token · Capability or Authorization Revalidation · Preflight Resource Probe · Revocation or Tombstone Check · Safe Missing-Referent Fallback · Stale Reference Monitor
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: Fuses the validity check and the dependent action into one indivisible operation, so no other actor can change the referent in between — there is no window to lose a race in, making its operative form a state-dependent executable control that senses, filters, routes, or actuates during operation.
Independent corroboration: The frozen evidence defines Atomic Check-and-Use Operation as 'Fuses the validity check and the dependent action into one indivisible operation, so no other actor can change the referent in between — there is no window to lose a race in', so its operative form is Control, Automation & Runtime.
Nearest alternative: Protocol, Workflow & Routine — The indivisible executable primitive enforces state consistency at runtime rather than relying on a manually followed sequence.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Atomic check-and-use operations arise from concurrent systems and security responses to time-of-check/time-of-use races.
Review outcome: Independent reviewer agreement; high confidence.
Notes¶
Atomic Check-and-Use is the pessimistic answer to the check-use race — serialize up front so no conflict can occur — while Compare-and-Swap or Version Guard is the optimistic dual: let work proceed and detect a conflict at commit. The pessimistic form wins under high contention or when a retry is expensive; the optimistic form wins when conflicts are rare and locking would waste throughput. Transactional Precondition Guard is the same guarantee scaled from a single operation to a multi-step unit with rollback.
[n1] Linearizability is the correctness condition (Herlihy and Wing) under which an operation appears to take effect instantaneously at a single point between its invocation and its response. An atomic check-and-use is the archetypal linearizable operation: check and use share one indivisible instant. ↩