Compare-and-Swap or Version Guard¶

Optimistic-concurrency guard — instantiates Use-Time Referent Validation

Carries the version, state, or token seen when the referent was read, and permits the action only if the referent still bears that exact marker at commit — otherwise it rejects rather than clobbers.

Version: v1 · 2026-08-24 · History
Mechanism #: 1608
Type: Protocol
Form family: Control, Automation & Runtime
Solution family: Buffering & Reserves
Problem family: Identity, Provenance & Integrity Failure
Problem subfamily: Execution-Time Referent & Repeat Integrity
Origin domain: Computer Science & Software Engineering
Instantiates: Use-Time Referent Validation

Compare-and-Swap or Version Guard is the optimistic answer to the check-use race. It does not lock the referent or serialize access up front; it lets work proceed and catches conflict at the last step. When the referent is read, the mechanism captures a marker of its exact state — a version counter, a content hash, an ETag, a timestamp — and carries it to the moment of commit. The action is applied only if the referent still bears that marker; if the marker has moved, someone else changed the referent in the meantime, and the operation is rejected and retried rather than blindly overwriting a state it never saw. Its signature is that a mismatch is the signal: change is detected after the fact by comparing versions, not prevented by holding a lock.

Example¶

Two editors open the same wiki page, both at version 47. Editor A saves first; the page becomes version 48. Editor B, still holding 47, clicks Save. The version guard compares B's expected 47 against the store's current 48, sees they differ, and rejects the write — "this page changed since you loaded it" — instead of silently overwriting A's edit. B is shown the diff and re-applies the change onto 48, which now saves because expected and current agree. No update is lost; the conflict surfaces as an explicit reject rather than a silent clobber.

How it works¶

Capture a version marker at read. Record the referent's exact state token — counter, hash, ETag, timestamp — when it is first read.
Re-present it at commit. Carry the captured marker to the write and hand it back to the store as a precondition.
Swap only on match. The store applies the change only if current equals expected, and bumps the version on success — done as one atomic compare-and-set so the compare and the write cannot themselves be split.
Reject and retry on mismatch. A differing marker means the referent moved; the operation fails and is retried against the fresh state rather than forcing a stale write through.

Tuning parameters¶

Version-token type — monotonic counter, content hash, timestamp, or ETag. Determines what "changed" means and how coarse or forgeable the marker is.
Conflict resolution — reject, auto-retry, or attempt a merge on mismatch. Sets who does the reconciling and how much is automatic.
Granularity — whole-record versus per-field versioning. Finer versioning cuts false conflicts but costs bookkeeping.
Retry policy — how many retries and with what backoff. Bounds live-lock when many writers contend.
Staleness tolerance — whether a slightly old version is still acceptable for this action. Loosening lifts throughput but risks acting on stale state.

When it helps, and when it misleads¶

Its strength is lock-free throughput: under low-to-moderate contention it delivers safety without anyone holding a lock, which is why it is the backbone of optimistic concurrency control. It also makes conflicts explicit — a rejected write instead of a silent lost update — which is exactly the failure a naive read-modify-write hides.

Its subtle trap is the ABA problem: if the referent changes from A to B and back to A between read and commit, a coarse marker looks unchanged when the state is not, and the guard is fooled into swapping.^[n1] A strictly monotonic or content-derived token avoids it; a bare value reused as its own marker does not. Under high contention the retries pile up and throughput can collapse below what a lock would give. The classic misuse is a weak or reused token that yields a false "unchanged." The disciplines: use a monotonic or content-derived marker, and bound the retries.

How it implements the components¶

identity_and_sameness_test — the compare step is a sameness test on the version: is this the exact state I read, or has the referent moved? (The "right intended thing" identity test at enumeration time is Preflight Resource Probe's facet; here the test is version-equality at commit.)
stale_reference_invalidation_signal — a version mismatch is the invalidation signal that the held reference is stale, triggering reject-and-retry rather than a blind write.

It detects a concurrent change but does not lock the referent up front — eliminating the window is Atomic Check-and-Use Operation's check_use_binding_boundary — nor does it re-resolve the referent at use (Just-in-Time Existence Check) or watch its staleness as a standing pattern (volatility_and_risk_profile, Stale Reference Monitor).

Instantiates: Use-Time Referent Validation — Compare-and-Swap or Version Guard supplies the "unchanged since I read it" precondition on the action.
Consumes: Atomic Check-and-Use Operation — the compare-and-swap itself must run atomically; the version guard is optimistic concurrency built on one indivisible compare-and-set.
Sibling mechanisms: Atomic Check-and-Use Operation · Stale Reference Monitor · Just-in-Time Existence Check · Lease, Lock, or Reservation Token · Transactional Precondition Guard · Capability or Authorization Revalidation · Preflight Resource Probe · Revocation or Tombstone Check · Safe Missing-Referent Fallback

Editorial Notes¶

Form Classification¶

Form family: Control, Automation & Runtime

Rationale: Carries the version, state, or token seen when the referent was read, and permits the action only if the referent still bears that exact marker at commit — otherwise it rejects rather than clobbers, making its operative form a live operational control that automatically routes, enforces, adapts, or responds during execution.

Independent corroboration: The frozen evidence defines Compare-and-Swap or Version Guard as 'Carries the version, state, or token seen when the referent was read, and permits the action only if the referent still bears that exact marker at commit — otherwise it rejects rather than clobbers', so its operative form is Control, Automation & Runtime.

Review outcome: Independent reviewer agreement; high confidence.

Origin Attribution¶

Primary origin: Computer Science & Software Engineering

Origin pattern: Single lineage

Present-day reach: Specialized

Rationale: Concurrent programming and database systems cohered compare-and-swap and optimistic version guards to reject writes computed from stale state.