Release Consistency¶
Release consistency relaxes ordinary shared-memory ordering while enforcing specified acquire/release synchronization boundaries for correctly labeled concurrent programs.
Core Idea¶
Classical release consistency separates ordinary shared-memory accesses from acquire/release synchronization. It relaxes ordinary ordering between boundaries while requiring particular order around acquire and release. The original SC-equivalence result is conditional on properly labeled programs under RCsc, not an unconditional guarantee for all concurrent code.[^ref-4e7c736c480f]
Scope of Application¶
The original work applies to hardware multiprocessors such as Stanford DASH, with cache/fence mechanisms enforcing event-order requirements. Software DSM systems such as TreadMarks implement a lazy variant across workstations, transferring modification information as successors need it. C/C++ acquire-release atomics are related but not identical to this classical model.[ref-4e7c736c480f][ref-62d2733b8c93][^ref-24b4209ef2e9]
Clarity¶
A lock-protected writer acquires, updates ordinary shared data, then releases. A later lock owner acquires before reading the data. The synchronization labels tell an implementation where ordering matters. “Release” does not mean every changed byte must be broadcast at that instant; TreadMarks can send write notices and fetch page differences only when the successor accesses the page.[ref-4e7c736c480f][ref-62d2733b8c93]
Manages Complexity¶
The model avoids imposing a global sequential interleaving on every ordinary access, potentially enabling buffering and overlap. The cost is correct classification and protection of competing accesses plus implementation bookkeeping for fences, intervals or diffs. A missed synchronization invalidates the easy correctness argument.[ref-4e7c736c480f][ref-62d2733b8c93]
Abstract Reasoning¶
Classify ordinary, acquire and release events; apply the variant's ordering rules at boundaries; then check whether all relevant conflicts are properly labeled. Only for that condition may the original RCsc theorem equate outcomes with SC. C/C++ explicit acquire-release has standard-specific limitations and cannot borrow that theorem unchanged.[ref-4e7c736c480f][ref-24b4209ef2e9]
Knowledge Transfer¶
Hardware DASH and software TreadMarks share boundary ordering but not physical propagation. DASH uses multiprocessor cache/fence behavior; TreadMarks uses lock intervals, notices, invalidation and on-demand diffs. The portable skeleton stays within shared-memory ordering, not a generic handoff prime. The live Consistency Model prime is the strict genus for permitted observation histories.[ref-4e7c736c480f][ref-62d2733b8c93]
[^ref-4e7c736c480f]: Gharachorloo et al., original release-consistency model, §§3.2–3.3, 4 and 6.3. [^ref-62d2733b8c93]: Keleher et al., TreadMarks original protocol, §§2.2 and 3. [^ref-24b4209ef2e9]: ISO WG14 N1479 memory-model rationale, explicit atomics ordering.
Relationships to Other Abstractions¶
Current abstraction Release Consistency Domain-specific
Parents (1) — more general patterns this builds on
-
Release Consistency is a kind of Consistency Model Prime
Release consistency is a shared-memory consistency model.
Hierarchy paths (2) — routes to 2 parentless roots
- Release Consistency → Consistency Model → Contract → Interface → Boundary
- Release Consistency → Consistency Model → Concurrency
Neighborhood in Abstraction Space¶
Release Consistency sits in a sparse region of the domain-specific corpus (66th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.
Family — Distributed Systems Theorems & Fallacies (19 abstractions)
Nearest neighbors
- Sequence number — 0.85
- Communicating X-machine — 0.85
- Cache-Only Memory Architecture — 0.84
- Non-Blocking Algorithm — 0.84
- Unit of Work — 0.84
Computed from structural-signature embeddings · 2026-10-08