Policy-Synchronized Deterministic Memory

• PSM is a compositional abstraction for race-free, concurrent updates to shared memory using type-directed, policy-synchronized methods.
• It coordinates lock-step thread execution through transactional memory and predefined precedence rules to manage destructive updates.
• PSM guarantees determinacy by enforcing commutativity of concurrent operations and verifying policy constraints via a rigorous type system.

Policy-Synchronized Deterministic Memory (PSM) is a compositional abstraction for race-free, concurrent, imperative updates to shared memory, synthesized via policy-coordinated accesses. PSM enables deterministic parallel and concurrent programming for imperative data structures by extending the Haskell concurrency ecosystem with a type-directed policy discipline that guarantees, by construction, the determinacy of well-typed computations. Threads in PSM can share state, perform destructive updates, and progress in lock-step under a programmer- or library-defined synchronization policy, thereby bridging a longstanding gap between determinacy and mutability in functional parallel programming (Mendler et al., 18 Jun 2025). The PSM framework is realized via a core API, operational semantics, and rigorously proven determinacy theorems.

1. Formal Abstraction and Type Structure

PSM augments Haskell's parallel and concurrent paradigms by providing a new type context, denoted PSM a, for computations in which shared state is updated imperatively yet deterministically under policy synchronization. The main types and type classes are:

• PSM a: The policy-synchronized monad for concurrent, lock-step threads.
• PSMVar a: A shared variable of type a, with associated policy governing access.
• PSMVal a: A thread-local, unsynchronized value context.
• PSMType a (typeclass): Dictates the static and dynamic structure, schedule, and allowed methods for each shared data type, and encodes the policy (ordering, admissibility, and precedence) for access.

The key operational rules in PSM are:

• Thread creation and synchronization: fork, pause (global tick barrier), and policy-controlled method invocation.
• Access discipline: Before each method call on a shared variable, policy predicates are checked transactionally in STM; if the policy is not satisfied, the access retries and thus threads block until coordinated.
• Fork–join and sequencing: Parallel and serial composition are supported, and their typing is enforced at the type-system level to guarantee safe, race-free interactions.

2. Policy Coordination and Runtime Mechanism

A policy in PSM is represented by a triple $(\text{PSMState}\;a,\, \text{MethodId},\,\prec)$, where:

• $\text{PSMState}\;a$ is the internal state of a PSMVar.
• $\text{MethodId}$ enumerates the methods on the structure.
• $\prec$ is a precedence function: $\prec(s, m)$ returns a set of methods that must finish before $m$ is admissible in state $s$.

Policy coordination at runtime proceeds as follows:

• The scheduler, implemented via STM (Software Transactional Memory), checks for each method invocation whether the policy allows it—if not, the transactional action retries and blocks.
• Two “potential” counters per shared variable (transient and recurrent) are used to track prediction of calls and loop heads, enabling global macro-step (tick) barriers for tightly synchronized execution.
• The Cox–Rowers protocol, instantiated as a library PSMVar, acts as a distributed barrier: at each tick, all predictions and ready signals are processed to ensure all threads are synchronized before advancing.

This mechanism ensures that, at each macro-step, all admissible operations on shared memory are coordinated and that determinacy is preserved even in the presence of complex, nested parallel and imperative computations.

3. Determinacy Guarantees and Proof

PSM's central property is the determinacy theorem, formalized as follows:

Let each PSMVar in a given program be “locally coherent.” That is, for any two concurrent method calls $m_1, m_2$ on state $s$ with no precedence relation enforced between them, their effects commute (the final store and result are invariant to execution order). Under this coherence property,

• Theorem (Determinacy): For any initial program state, any complete run of a PSM computation yields the same result and final store, regardless of thread interleaving or scheduling (Mendler et al., 18 Jun 2025).

The proof uses standard operational semantics: STM guarantees atomic updates, the policy ensures confluence by requiring pairwise commutativity of concurrent actions, stability guarantees that enabled methods remain enabled, and the global clock-tick step only reorders completed macro-steps, preserving finality.

4. Data Structures Realized in PSM

Several common synchronization and shared-memory abstractions are expressed as instances of PSMType, including:

Data Structure	Synchronization Policy	Key Methods
Barrier (Cox–Rowers)	Inc/Dec/Zero methods; Zero waits for all Inc/Dec done	incPTSync, decPTSync, zeroPTSync
Race-free TVar (PTVar)	Write-before-read or read-before-write precedence	writePTVar, readPTVar
Updatable MVar (PMVar)	Put/Take/Upd with precise state-based precondition	putPMVar, takePMVar, updPMVar
Esterel-style Signal	Init/Emit/Pres/Read; constructive synchronous semantics	initPTSig, emitPTSig, presPTSig, readPTSig

In each case, the precedence relation $\prec$ ensures all method bodies either serialize safely (commute if invoked without ordering), or are precedence-blocked and hence race-free by construction.

5. Comparison to Existing Haskell Memory Abstractions

PSM draws a precise line between expressive power and determinacy guarantees, as summarized:

• Par/IVar: Only supports single-assignment, monotonic writes, always deterministic, no destructive update.
• LVar: Monotonic update plus threshold synchronization, always deterministic, but cannot model in-place mutation.
• IO/MVar: Allows destructive update and sharing, but introduces nondeterminism unless the user imposes external locks.
• STM/TVar: Supports compositional atomicity, but not determinacy—if two transactions concurrently write, order depends on STM scheduling.

PSM enables destructive update (like IO/MVar), supports compositional atomic transaction definitions (like STM), and guarantees determinacy (like Par/LVar), by embedding synchronization policies into the type system. Well-typed PSM programs are race-free and deterministic without global locks or explicit user reasoning about interleavings (Mendler et al., 18 Jun 2025).

6. Practical Considerations and Usage Guidelines

• Instance authors of the PSMType class are responsible for supplying policies for each shared data structure that establish the coherence property; this typically involves proving (informally) that method bodies commute as required by $\prec$.
• End users can use the provided combinators: newPSMVar, sequencing (>>>), (>>>=), parallelism (|||), pause-based barriers, and policy-lifted method application (runSTMMtd) to compose concurrent and parallel programs.
• Guarding recursion: Every recursive step should be guarded with pause or encoded via repUntil to ensure proper synchronization of speculative or iterative concurrent computations.
• Porting advice: To make an STM/TVar or MVar-based design deterministic under PSM, wrap each variable with newPSMVar and implement a suitable policy.

Current performance overheads stem from the STM-retry loop for policy waiting; future work may reduce this by integrating precedence logic directly with STM scheduling.

In summary, Policy-Synchronized Deterministic Memory establishes a disciplined framework for building deterministically behaving, mutable, and concurrent abstractions in Haskell. By integrating rich, type-directed synchronization policies, PSM enables a broad class of concurrency patterns beyond previous deterministic and imperative paradigms (Mendler et al., 18 Jun 2025).