Read-Write Separated Execution Architecture

• Read-write separated execution architecture is a design paradigm that segregates fast, latency-sensitive read operations from resource-intensive write operations to reduce contention.
• It leverages methods like OS-managed page migration, flexible I/O placement, and relaxed synchronization (e.g., multiplicity in work-stealing) to achieve efficient performance.
• Implementations in LtRAM systems, real-time scheduling, and large-scale search engines illustrate tailored tradeoffs between throughput optimization, resource allocation, and operational complexity.

Read-write separated execution architecture denotes a class of system designs in which read operations and write operations are prevented from sharing the same critical path, the same timing constraints, or the same resource-management mechanism. In main-memory systems, Application Read-Only Memory (AROM) makes LtRAM pages read-only to applications and writable only by the operating system during page migrations (Shim et al., 18 Jun 2026). In embedded real-time systems, flexible I/O placement for read-write tasks separates suspension-inducing I/O phases from computation so that scheduling can proceed without the usual suspension pessimism (Tong et al., 2014). In concurrent runtimes, multiplicity and weak multiplicity permit work-stealing algorithms in which Put, Take, and Steal use only read/write primitives and avoid read-after-write synchronization patterns, fences, and atomic read-modify-write instructions in the critical path (Castañeda et al., 2020). In large-scale search engines, read and write paths are isolated to reduce write-read contention caused by segment flushes, merges, and cache churn (Liang et al., 2 May 2026). At a more abstract level, the read/write protocol complex models asynchronous executions in shared memory and shows that operational progress can be interpreted as a sequence of collapses (Benavides et al., 2015). Taken together, these works suggest that read-write separation is a recurring systems principle rather than a single mechanism.

1. Conceptual scope and recurring invariant

Across the cited literatures, the core invariant is that the latency-sensitive or semantically simple path is assigned to reads, while writes are redirected to a separately controlled mechanism. The concrete reason varies by domain. LtRAM exposes asymmetric read/write latencies, limited endurance, and coarse write granularity, so direct application writes are prohibited and mediated by OS migration (Shim et al., 18 Jun 2026). Real-time I/O suspensions disrupt schedulability analysis when reads and writes are fixed to specific points in a task, so the phases are rearranged across job boundaries (Tong et al., 2014). Standard work-stealing requires exact ownership transfer and therefore stronger synchronization, so multiplicity weakens exactness enough to enable monotone read/write coordination (Castañeda et al., 2020). Lucene-derived search systems experience write-read contention through merges, disk I/O, and page-cache eviction, so query-serving and indexing are decoupled structurally (Liang et al., 2 May 2026).

Domain	Separation mechanism	Primary objective
LtRAM main memory	AROM with CoW-triggered migration	Avoid controller-side translation overhead
Real-time scheduling	Flexible I/O placement with GEDF-R/W	Eliminate suspension pessimism in schedulability test
Work-stealing	Multiplicity or weak multiplicity	Remove fences and atomic RMWs from critical operations
Search engines	Node, storage, memory, log, or field-level decoupling	Isolate query latency from write pressure
Shared-memory computability	Protocol-complex collapse	Structural characterization of read/write executions

This cross-domain alignment does not imply identical semantics. In some cases the separation is an enforcement rule on memory placement, in others it is an offline task transformation, a concurrency-specification relaxation, or a deployment architecture. The commonality lies in removing writes from the fast or analytically fragile path.

2. Operating-system-managed separation in LtRAM memory systems

"The Kernel's Write: Application Read-Only Memory" defines AROM by a single rule: LtRAM pages are read-only from the application’s perspective, and only the operating system writes to LtRAM, specifically during page migrations (Shim et al., 18 Jun 2026). Applications may read LtRAM-resident pages normally, but a store to such a page triggers copy-on-write. The kernel allocates a DRAM page, copies the LtRAM page into DRAM, updates the page table to the DRAM copy, and only then allows the store to execute against DRAM. The original LtRAM page is freed afterward, and its underlying block is scheduled for erase when the device is idle. The execution model is therefore explicitly read-write separated: reads may occur in place from LtRAM, while writes are forced onto a DRAM path.

The motivation is the failure of the DRAM-compatible abstraction exemplified by Optane-like modules. When the DIMM controller attempts to hide media asymmetry through an Address Indirection Table, AIT caches, read buffers, write-combining buffers, and internal wear-leveling migrations, those mechanisms appear on the critical path. The paper reports several concrete penalties: sub-256 B writes require read-modify-write behavior, causing roughly a 75% write-throughput drop; random reads pay an AIT lookup penalty on nearly every access because the on-DIMM AIT cache is too small; internal wear-leveling migrations inject tail-latency spikes of around 60 μs; and mixed read/write workloads cause bandwidth collapse. AROM removes these controller responsibilities by making the operating system responsible for page placement, migration, CoW fault handling, and endurance pacing.

Under this interface, the controller is reduced to three duties: accepting reads at cache-line granularity, accepting writes at 4 KB page granularity, and exposing cell-health metadata to the OS. Because writes are aligned to 4 KB pages, the controller no longer needs read-modify-write for sub-page stores; because it does not perform wear-leveling, it avoids AIT lookup overhead and migration-induced tail latency. The OS uses existing dirty-bit tracking at scan interval $T$: pages whose dirty bit is clear are migration candidates, while pages that were written have their dirty bit cleared for the next scan. Pages begin in DRAM unless they are read-only by construction, such as executable code, shared libraries, or read-only mmap’d files, in which case they may be placed directly in LtRAM. Cold, read-mostly pages migrate into LtRAM subject to an endurance budget, and a later write fault returns them to DRAM before modification.

Endurance management is formalized through a token allocator. If a device has $N$ pages, each rated for $E$ erases over deployment lifetime $T$ seconds, then the token issuance rate is

$r = NE/T$

tokens per second. Each migration into LtRAM consumes a token; if no token is available, the migration is deferred, and tokens can be banked during idle periods. This guarantees lifetime budget compliance by construction, although the paper explicitly notes that it does not automatically guarantee perfect wear uniformity across the chip.

The projected evaluation estimates that the proposed interface would be 26–79% faster than Optane, and, depending on the technology, between 10% faster and 220% slower than DRAM on raw per-access read latency. The stated design goal is to match the performance of pure DRAM on read-mostly workloads while delivering LtRAM’s density and cost advantages. The limitations are equally explicit: write-heavy workloads can cause every store to an LtRAM page to incur a CoW fault and migration to DRAM; out-of-memory faults during write-heavy phases remain open; dirty-bit scanning is simple but imprecise; and the prototype uses NOR flash on the Enzian platform as a stand-in for LtRAM.

3. Suspension-aware separation in embedded real-time systems

"Supporting Read/Write Applications in Embedded Real-time Systems via Suspension-aware Analysis" treats read-write separation as a scheduling architecture for sporadic real-time tasks on $m$ identical processors under global EDF (Tong et al., 2014). A read-write task has the form

$\tau_i=(R_i,C_i,W_i,T_i),$

with

$$U_i=\frac{C_i}{T_i}, \qquad V_i=\frac{R_i+W_i}{T_i}.$$

The problem is that read and write operations induce suspension delays, and if those suspensions are fixed to specific points in the job, conventional schedulability analysis becomes pessimistic. A suspended job is still pending, yet it is not eligible for computation until the suspension completes.

The proposed remedy is a flexible I/O placement policy. The original task stream is transformed so that job $\tau_{i,j-1}$ helps perform the reading phase of $\tau_{i,j}$, and job $N$0 helps perform the writing phase of $N$1. This creates a pipeline-like structure in which computation and suspension inside a job become independent enough that the scheduler can decide when computation runs and when suspension proceeds. The paper characterizes this explicitly as the “read-write separated execution” idea: I/O placement is decided during application programming, while execution order is controlled by the scheduler at runtime.

To exploit the transformed structure, the paper introduces GEDF-R/W. At each instant, GEDF-R/W selects the $N$2 comp-pending jobs with the earliest deadlines for computation; if a comp-pending job is not chosen and still has unfinished suspension, then it performs suspension instead. The analysis uses two idealized reference schedules: a processor-share schedule PS for computation and an SPS schedule for suspensions. With this machinery, the paper proves that under flexible I/O placement and GEDF-R/W, no job misses its deadline if

$N$3

This is exactly the ordinary density test for suspenseless tasks. The paper therefore states that the negative impact of suspension is completely eliminated in the schedulability test.

The contrast with the write-only model is important. For write-only tasks, the paper derives a suspension-aware condition with

$N$4

and

$N$5

where

$N$6

That result yields only $N$7 suspension-related utilization loss, which is already a substantial improvement over suspension-oblivious analysis. The read-write model goes further by altering the execution structure itself rather than only tightening the analysis.

The case study on matrix-processing applications illustrates the practical effect of the separation. Under the original structure and ordinary GEDF, some jobs show unbounded or highly variable response times. Under GEDF-R/W on two processors, a task whose response time under GEDF ranges roughly from 1150 ms to 1550 ms is reduced to about 920 ms with much less variance. The assumptions, however, are specific: tasks are independent sporadic tasks with implicit deadlines, processors are identical and globally scheduled, jobs may migrate, time is discrete, I/O device contention is ignored in the main model, and migration overhead is not modeled in the formal bound.

4. Fence-free separation in work-stealing runtimes

"Fully Read/Write Fence-Free Work-Stealing with Multiplicity" studies a different bottleneck: the synchronization cost of exact work-stealing in the standard asynchronous shared-memory model (Castañeda et al., 2020). In conventional work-stealing, Put and Take are executed by the owner of a task set, and Steal is executed by thieves. Standard exactness requires strong coordination, typically through a shared head variable whose updates must be tightly synchronized with reads of the task array. This induces a write-then-read synchronization pattern associated with the flag principle, and in practice leads to fences or atomic read-modify-write instructions such as CAS or F&A.

The paper’s solution is to relax semantics just enough to make read/write separation possible. In work-stealing with multiplicity, every task is taken by at least one operation, and if multiple operations take the same task, they must be pairwise concurrent. In work-stealing with weak multiplicity, every task is taken at least once, different thieves may take the same task even if not all are pairwise concurrent, but each process still extracts a given task at most once. These relaxations replace exact handoff with monotone progress tracking.

The coordination object is correspondingly weakened. The multiplicity algorithm uses a monotone Max-style Head object that never moves backward. The weak-multiplicity algorithm introduces a range-max register $N$8 in which each process maintains a local variable $N$9, read returns some value between the local $E$0 and the maximum value held by all processes, and updates are monotone and local-first. Because these objects are monotone, the algorithms can avoid required write-then-read orderings. The owner’s Put writes the task and pre-initializes a future slot with ⊥; Take reads Head, inspects the corresponding slot, and advances Head; Steal reads Head, inspects the slot, and may also advance Head. The algorithms are structured so that paired writes may occur in any order and no fence is required.

The resulting guarantees are strong within the relaxed specifications. The multiplicity algorithm is wait-free, set-linearizable, and fence-free, with constant step complexity for all operations when Head is a unit-cost object, or $E$1 if Head uses the polylogarithmic max-register construction from Aspnes et al. The weak multiplicity algorithm is linearizable, sequentially exact, wait-free, fence-free, and every operation has constant step complexity. The paper emphasizes that this is achieved in the standard asynchronous model rather than under TSO, and without CAS or locks in the critical operations.

A central clarification is that this form of read/write separation is enabled by a semantic relaxation. The paper explicitly distinguishes multiplicity from idempotent work-stealing: idempotent work-stealing may allow a task to be extracted an unbounded number of times, even by the same thief multiple times, whereas multiplicity bounds duplication to at most $E$2 and requires concurrent duplication. A plausible implication is that the architectural gain—fence-free read/write-only synchronization—derives from replacing exact exclusivity with a monotone, concurrency-bounded notion of progress.

5. Decoupled read and write paths in large-scale search engines

"Write-Read Decoupling in Modern Large-Scale Search Engines: Architectures, Techniques, and Emerging Approaches" presents read-write separation as the organizing principle of modern search architecture (Liang et al., 2 May 2026). In the classical Lucene segment model, documents accumulate in RAM, a refresh flushes them into a new immutable segment, a flush fsyncs and clears the transaction log, and background merges combine small segments into larger ones. The resulting write-read contention appears through CPU contention between merge threads and query threads, disk I/O and page-cache eviction, and segment explosion caused by frequent refreshes. In Elasticsearch’s shared-nothing replication model, every replica reruns the full indexing pipeline, so write work grows roughly by $E$3, and write amplification can reach 10–30× under sustained ingestion.

The survey identifies five principal patterns for decoupling writes from reads: node-level read-write separation, compute-storage separation, full in-memory indexing, log-structured write paths, and in-place partial updates.

Pattern	Representative systems	Main effect
Node-level read-write separation	LinkedIn Galene, Uber Sia	Searchers avoid live indexing
Compute-storage separation	Quickwit, Elasticsearch Stateless / Search AI Lake, OpenStore	Read and write fleets scale independently
Full in-memory indexing	Algolia, Typesense, Ximalaya	Queries avoid disk I/O and page-cache dependence
Log-structured write paths	Milvus, Havenask / HA3	Durability separated from derived searchable structures
In-place partial updates	Vespa	Scalar-field updates bypass segment construction

Each pattern isolates the query path differently. In Galene, Indexer nodes consume Kafka streams, build Lucene segments, and periodically force-merge snapshots, while Searcher nodes load and serve snapshots only. In Sia, ingestion services built on Apache Flink create segments offline, publish them to object storage, and searcher nodes remain stateless consumers. Quickwit stores immutable splits of about 1–15 GB in object storage; search nodes are fully stateless, fetch a small hotcache footer first, and then use HTTP range requests, often requiring at most three network round trips per split per query. Full in-memory systems move the serving path entirely into DRAM: Algolia maintains RAM-resident structures and atomically swaps incremental in-memory copies, Typesense uses an Adaptive Radix Trie, and Ximalaya reports a reduction from about 50 ms to under 5 ms average query latency. The tradeoff is memory cost, often 3–10× raw data size.

The survey’s most elaborate synthesis is ScaleSearch, which targets billion-document search, P99 under 50 ms, and sub-minute freshness. ScaleSearch combines compute-storage separation, full in-memory indexing, dedicated write nodes, and per-field update routing. A Write Node receives document updates for a shard, runs a custom Lucene-inspired segment writer, creates immutable segment files, and uploads them asynchronously to S3. A Search Node downloads segment files on startup, builds a full in-memory inverted index from them, polls object storage for new segments, and merges new segments into RAM only, with no disk I/O.

Per-field update routing sharpens the separation further. Fields are grouped into column families based on freshness SLA, and within each column family each field has its own Kafka topic. Scalar fields such as price, stock_level, tags, and rank_score are written directly to a Search Node’s in-memory forward array in $E$4 RAM with immediate visibility. Full-text fields such as title, description, and category_text follow the segment path through Write Nodes and object storage. The paper argues that this avoids sending the common case of scalar-state updates through the heavy Lucene path. Open issues remain in hybrid full-text plus vector retrieval, serverless deployments, AI-integrated search, and the role of hardware trends such as CXL memory pooling and disaggregated memory.

6. Formal read/write execution and the protocol-complex perspective

"The read/write protocol complex is collapsible" addresses read/write execution at the level of asynchronous computability rather than systems deployment (Benavides et al., 2015). The model consists of $E$5 deterministic processes communicating through a shared memory array of single-writer/multi-reader atomic registers. In the one-round read/write model, process $E$6 first writes its input to its own register and then reads all registers in arbitrary order; this combined action is abbreviated as

$E$7

Executions are arbitrary interleavings of atomic operations, and the local view of process $E$8 in execution $E$9 is $T$0.

The paper studies the family of protocol complexes

$T$1

where vertices are pairs $T$2 and simplices correspond to sets of local states that can arise together in one execution. The inclusion chain

$T$3

encodes the fact that later rounds impose stronger constraints on possible views. The central theorem is that for all $T$4,

$T$5

and moreover this collapse is compatible with the natural action of the symmetric group $T$6.

The proof identifies simplices not belonging to $T$7, partitions them into disjoint intervals $T$8, and collapses these intervals by removing free faces. The paper further shows that the iterated read/write protocol complex also collapses to the iterated chromatic subdivision:

$T$9

A significant conceptual claim is that a distributed protocol implementing atomic snapshots is, in effect, performing these collapses. Processes write, scan, decide whether to stop or recurse, and the complex is peeled away accordingly.

This use of “read/write execution” differs from the architectural usage in memory systems, scheduling, runtimes, and search. It is not a technique for isolating reads from writes on a fast path. Instead, it provides a structural account of how read/write communication models relate to snapshot and immediate snapshot models. The connection is therefore formal rather than operational: the paper shows that the space of read/write executions has no hidden topological complexity beyond the snapshot complex.

7. Tradeoffs, misconceptions, and open directions

A common misconception is that read-write separation always means placing reads on one machine and writes on another. The surveyed literature shows several non-equivalent forms. In AROM, the separation is semantic and enforced by page protection: applications may read LtRAM, but only the kernel writes to it during migration (Shim et al., 18 Jun 2026). In real-time scheduling, the separation is a transformation of job structure and scheduler behavior rather than a physical partition (Tong et al., 2014). In work-stealing, it is enabled by weakening exactness to multiplicity or weak multiplicity (Castañeda et al., 2020). In search engines, it ranges from node-role specialization to per-field routing and memory-resident fast paths (Liang et al., 2 May 2026). In distributed computability, the phrase belongs to a mathematical model of shared-memory execution (Benavides et al., 2015).

The tradeoffs are likewise domain-specific. AROM is best suited to read-mostly workloads; if a workload becomes write-heavy, every store to an LtRAM page incurs a CoW fault and migration to DRAM, which can exhaust DRAM free space and lead to out-of-memory faults. Flexible I/O placement in real-time systems assumes sufficiently available I/O devices and does not model migration overhead. Fully fence-free work-stealing changes the problem specification by allowing controlled duplication under concurrency. Search-engine decoupling often trades freshness against stability, or query predictability against DRAM cost and cold-start penalties. The protocol-complex results do not address performance at all; they address collapsibility and equivalence of execution spaces.

These results suggest that read-write separated execution is most effective when asymmetry is explicit rather than hidden. LtRAM does not behave like DRAM; suspending I/O does not behave like pure CPU demand; exact work-stealing does not admit the same synchronization profile as multiplicity-based stealing; and update-heavy search indexing does not behave like immutable query serving. A plausible implication is that the architecture succeeds when it exposes these asymmetries to the operating system, the scheduler, the runtime, or the deployment topology, and fails when it attempts to erase them behind a uniform interface.