Deterministic Store Mechanism in TSO

• Deterministic store mechanism is a programming discipline that guarantees predictable memory updates and sequential consistency in concurrent systems.
• It leverages ghost state reasoning, memory address ownership, and explicit flushing policies to mitigate non-determinism introduced by store buffers.
• Formal verification in a mechanized proof environment validates its effectiveness, reducing synchronization overhead without relying on ubiquitous locking.

A deterministic store mechanism refers to a systematic method or protocol that ensures deterministic behavior (repeatability and predictability) in the management of stored data, memory updates, or intermediate states—particularly in concurrent systems, language acceptors, and computational models. In the context of "A Better Reduction Theorem for Store Buffers" (0909.4637), the deterministic store mechanism is characterized by a programming discipline that enforces sequential consistency in the presence of relaxed hardware memory models, notably Total Store Order (TSO), without requiring ubiquitous locking. This mechanism is grounded in ghost-state reasoning, memory address ownership, and rigorous access policies, and is formally verified in a mechanized proof environment.

1. Store Buffers and Their Impact in Concurrent Systems

Modern multiprocessors incorporate store buffers—small per-processor FIFO queues that hold writes before propagating them to shared memory—primarily for performance. When a processor performs a write, it enters the buffer and becomes visible to that processor’s subsequent reads (buffer forwarding), but remains invisible to other processors until it is globally committed. This architectural optimization introduces potential for non-sequentially-consistent behaviors, where memory operations may be observed out of their intended program order by other processors. A well-known illustration is that, under TSO, two threads writing and immediately reading different variables can see each other's writes out of order, a situation not possible under sequential consistency.

The non-determinism introduced by store buffers complicates both reasoning about program correctness and the formal verification of concurrent software. If store buffer behaviors must be explicitly modeled, the complexity of even basic operations increases, elevating the logic to undecidability for two threads. This motivates the need for a deterministic programming discipline that can restore predictable program behavior abstracted from hardware-specific effects.

2. Discipline for Deterministic Store Access under TSO

The central contribution of Cohen and Schirmer is a programming discipline for TSO that achieves deterministic store semantics without reliance on traditional synchronization primitives such as locks.

Ownership and Ghost Operations

Each memory address is tracked with abstract (ghost) state:

• Ownership: An address may be owned (by exactly one thread), unowned (shared), read-only, or unshared (thread-local).
• Ghost acquire/release: Threads acquire or release ownership via ghost operations—logical, non-runtime, evidence-tracking instructions.

Ghost operations allow flexible manipulation of ownership without incurring a runtime cost. These operations serve to encode invariants and track which thread is responsible for a memory location at any point.

Access and Flushing Policies

Operations are marked as volatile or non-volatile:

• Volatile accesses (reads/writes) are for shared addresses and require that reads see the most up-to-date value globally.
• Non-volatile accesses are used with thread-local or read-only addresses.

Soundness (safety) for each access is enforced through the following (summarized from the paper’s table):

Ownership / State	shared (rw)	shared (ro)	unshared
owned	vR, vW, R	unreachable	vR, vW, R, W
owned by other	vR	unreachable
unowned	vR, vW	vR, R	unreachable

• vR: volatile read, vW: volatile write, R: non-volatile read, W: non-volatile write.

Cleanliness: Read operations must be "clean," meaning the thread's store buffer has been flushed since the most recent volatile write (or, for non-volatile accesses, since acquiring the address). Flushing is required prior to such reads but not on writes, minimizing costly synchronization operations (e.g., fences).

Flushing triggers:

• Interlocked read-modify-write: implicit flush.
• Volatile and normal reads: explicit flush if not clean.
• Writes: do not require a flush in this discipline.

3. Guaranteeing Sequential Consistency: Discipline Enforcement and Formal Verification

The deterministic store mechanism is guaranteed by operationally coupling two models:

• Store Buffer Machine: The real hardware model, including buffers.
• Virtual (Sequentially Consistent) Machine: An idealization with instantaneously global, visible memory operations.

The main theoretical result asserts that if a program’s executions are discipline-conformant in the virtual machine (i.e., it only performs sound, clean accesses and uses ghost state correctly), then any execution in the real machine with store buffers will be sequentially consistent: all possible interleavings can be simulated as if no store buffers exist. This reduction is formalized and proven in Isabelle/HOL, establishing that reasoning about concurrent programs for TSO can be undertaken in the familiar and tractable domain of sequential consistency by simply adhering to the deterministic discipline.

Locks become a degenerate case of the discipline: they can be modeled by owning a particular memory address representing the lock, employing volatile writes to acquire/release, and using the ownership and soundness invariants as described.

4. Mechanization and Formal State Invariants

The discipline is embedded in a small-step operational semantics with explicit ghost state components:

• Dirty bit ($D$) tracks whether a volatile write is pending in the buffer.
• Owned addresses set ($O$) and recently acquired addresses ($A$), capturing the status of memory allocations.
• Safety judgement ($\vdash \mathit{conf} \,\checkmark$), ensuring accesses are made only when ownership and buffer flushing ("cleanliness") conditions hold.

A representative formal judgment for a volatile read is:

$\inferrule{ a \in O \vee a \in \texttt{read\_only}(S) \vee (\texttt{volatile} \wedge a \in \texttt{dom}(S)) \ \texttt{volatile} \Longrightarrow \neg D \ \neg \texttt{volatile} \Longrightarrow a \in A \Longrightarrow \neg D }{ \mathit{conf} \vdash \texttt{Read volatile}\ a\ t :: \checkmark }$

The discipline is mechanized to facilitate both verification and automated reasoning, separating the concerns of memory model and program correctness.

5. Impact on Programming Practice and System Design

Adoption of the described deterministic store mechanism has concrete practical implications:

• Programming flexibility: Accommodates both coarse-grained (e.g., monitor locks) and fine-grained (e.g., lock-free, atomic RMW) concurrency paradigms within a uniform reasoning framework.
• Efficiency: Reduces unnecessary buffer flushes and synchronization; only essential synchronization points, identified by the clean discipline, result in costly hardware barriers.
• Modularity: Compatible with program logics and verification tools aimed at sequential consistency; the store buffer details are abstracted from verification logic if the discipline is enforced.
• Performance scalability: Performance penalties due to store buffers are minimized, as flushes and ownership transfers are performed only when strictly necessary.

This mechanism enables higher-performance multiprocessor software by reducing the dependence on heavyweight, global synchronization (i.e., locks), and allows scalable, modular, and assertive program verification.

---

Key Formulas and Formal Rules

• Valid store operation:

$$\texttt{valid\_sop}\ sop \equiv \forall D\ f\ j.\ (sop = (D, f) \land D \subseteq \text{dom}(j)) \implies f(j) = f(j|_D)$$

• Cleanliness: A read is clean iff the store buffer has been flushed since the last volatile write (and for non-volatile, since ownership was acquired).

---

Summary Table: Policy for Reads and Writes

Access Type	Ownership Required	Buffer Flush?
Volatile Write	Not owned by others; not read-only	No
Non-volatile Write	Own and unshared	No
Volatile Read	Shared or own	Must be clean
Non-volatile Read	Own/unshared or shared/read-only	Must be clean

---

A disciplined, ghost-state-based deterministic store mechanism as described in this work provides a foundation for the construction and verification of high-performance, correct concurrent software under TSO and similar relaxed consistency models. The approach generalizes beyond coarse-grained locking to support fine-grained, flexible concurrency schemes while making correctness properties tractable and verifiable in the sequentially consistent setting.