--- title: Write–Manage–Read Loop url: https://www.emergentmind.com/topics/write-manage-read-loop type: topic --- # Write–Manage–Read Loop The Write–Manage–Read loop is a recurrent systems pattern in which new state is first written, then stabilized, reorganized, or migrated by an intermediate management phase, and finally exposed to a read mechanism. In the cited literature, this pattern appears in materially different substrates: B2-ordered FeRh antiferromagnetic memory uses Joule heating and field cooling to set a Néel vector before anisotropic-magnetoresistance readout; large-scale search engines interpose merges, compactions, and index-structure builds between ingest and query serving; explicit-memory LLMs insert and retrieve relational triples; a 3T-1R MRAM true random number generator couples analog write, reset, and digital read within a single period; and Application Read-Only Memory shifts Long-term RAM management into the operating system through copy-on-write migration [1507.06138] [2605.01260] [2404.11672] [2305.14322] [2204.14204] [2606.26138]. This suggests a cross-domain abstraction in which the central design problem is not merely storing information, but controlling the intermediate transformations that make stored state reliable, queryable, or physically realizable. ## 1. Phase structure and formalization In the search-engine formulation, the loop is explicitly decomposed into writes, management tasks, and reads. Documents are first placed into an in-memory buffer of capacity $M$ and flushed as immutable segments of size $S_0 \approx M \cdot s_p$; management then performs merges whose total work over $N$ documents is $W_m = O(N \cdot s_p \cdot \log(N/M))$ with write amplification $WAF \approx L$, where $L = \lceil \log_2(N/M) \rceil$; the read phase intersects postings from up to $O(L)$ active segments, with $\mathrm{CPU}_{\mathrm{read}} \approx O(P_q + L \cdot C_{\mathrm{seek}})$ [2605.01260]. That formulation makes the intermediate phase explicit: management is the mechanism that bounds downstream read cost, but it is also the source of contention. The broader record shows that the same three-part decomposition persists even when the management stage is not a merge. In the MemLLM-style MAuLLM description, writes add triples to an external memory, but the management phase does not rewrite stored triples; instead it removes a read call from prompt context when the retrieved set is empty, when $|\mathcal E| > Q_{\mathrm{thr}} = 30$, or when a new `MEM_READ` begins [2404.11672]. In RET-LLM, management is defined by append or overwrite policy plus index maintenance over three LSH tables [2305.14322]. In AROM, management is page migration, write protection, dirty-bit scanning, and token-bucket wear leveling rather than direct data-structure optimization [2606.26138]. In FeRh memory, management is thermal stabilization of the Néel vector after the write pulse [1507.06138]. In the 3T-1R MRAM TRNG, management is a deterministic reset that restores the device to anti-parallel state before the next stochastic write [2204.14204]. | Domain | Write | Manage | Read | |---|---|---|---| | FeRh antiferromagnetic memory | Joule-heating AF$\rightarrow$F transition with field cooling | Thermal lock-in of the AF state | AF-AMR measurement | | Search engines | Index updates and segment flushes | Merges, compactions, index-structure builds | Query processing over active structures | | Explicit-memory LLMs | Triple extraction and insertion into external memory | Prompt pruning, overwrite/append policy, index maintenance | Memory retrieval and continuation | | 3T-1R MRAM TRNG | Analog STT pulse | Deterministic reset to AP | Comparator and DFF readout | | AROM | Application store triggers CoW migration path | Page scanning, remapping, wear pacing | DRAM or LtRAM load | A common misconception is that “management” must denote a persistent rewrite of the same state representation. The cited systems show otherwise. Management may instead be thermal relaxation, prompt-context pruning, reset-to-known-state, or OS-level remapping. What is invariant is the insertion of an intermediate control phase between production of state and its subsequent observation. ## 2. Physical realizations in magnetic devices In B2-ordered FeRh, the write phase exploits the antiferromagnetic-ferromagnetic phase transition near room temperature. The staggered moment is defined as $\mathbf L = \mathbf M_A - \mathbf M_B$, and a minimal phenomenological free energy is written as $$ F(\mathbf L,T,H) = \tfrac12 a(T-T_0)\mathbf L^2 + \tfrac14 b|\mathbf L|^4 - \mathbf H \cdot \mathbf M(\mathbf L) +\dots $$ with $T_0 \approx 380\,\mathrm K$ as the bulk AF–F transition temperature. A current pulse $I_{\rm Hi}$ raises the temperature by $$ \Delta T \approx \frac{I_{\rm Hi}^2 R t_{\rm pulse}}{\rho c V}, $$ and in the reported $1\,\mu\mathrm m \times 42\,\mathrm{nm} \times 10\,\mu\mathrm m$ wire the AF$\rightarrow$F transition begins at $|I| \approx 7\,\mathrm{mA}$ and is complete by $|I| \approx 12\,\mathrm{mA}$, corresponding to $J_c \approx 2.0 \times 10^{11}\,\mathrm{A/m^2}$. While the wire is in the ferromagnetic phase, a $3\,\mathrm{kOe}$ in-plane field $\mathbf H_{\rm FC}$ sets the moment direction; the current is then reduced to $I_{\rm Lo} = 0.5\,\mathrm{mA}$, and cooling below $T_0$ freezes an AF state with $\mathbf L \perp \mathbf H_{\rm FC}$ [1507.06138]. The management phase in FeRh is thermal and anisotropy-governed rather than algorithmic. The barrier is approximated by $E_a \approx K_u V_{\rm AF}$, with relaxation time $$ \tau_{\rm relax} = \tau_0 \exp(E_a/k_B T). $$ The supplied description states that even with modest $K_uV/k_B T \sim 40$, $\tau_{\rm relax}$ reaches days to years, and that the written Néel order is unchanged by in-plane disturbing fields $\le 2\,\mathrm{kOe}$. The read phase uses antiferromagnetic AMR, $$ R(\theta) = R_\perp + \Delta R \cos^2\theta, $$ implemented as a crossed-wire ratiometric measurement of $R/R_{\rm ref}$. The total $\Delta R/R$ between the “parallel” and “perpendicular” AF states is $0.011\%$, the AF-AMR after subtracting residual ferromagnetic background is approximately $0.008\%$, and the single-read accuracy is better than $10\,\mathrm{ppm}$. The proof-of-concept demonstrates more than $10^2$ sequential write-read cycles with no degradation of contrast. Heating and cooling in the present experiment take order $1\,\mathrm s + 30\,\mathrm s$ for full thermal stability, while the device physics is stated to allow sub-nanosecond pulses with optimized thermal design [1507.06138]. The 3T-1R analog-write/digital-read MRAM TRNG instantiates a different physical loop. A single period $T$ contains a stochastic analog write of duration $t_{\mathrm write} \simeq 3$–$3.5\,\mathrm{ns}$, a deterministic reset of duration $t_{\mathrm reset} \simeq 2$–$3\,\mathrm{ns}$, and a digital read of duration $t_{\mathrm read} \lesssim 1\,\mathrm{ns}$, for a total period of approximately $7\,\mathrm{ns}$ and a bit rate of about $140\,\mathrm{MHz}$. The write uses $I_{\mathrm write} \simeq 0.5\,\mathrm{mA}$, $V_{\mathrm write} \simeq 1\,\mathrm V$, and $R_{\mathrm MTJ} \approx 1.8\,\mathrm{k}\Omega$ to set a switching probability near $0.5$; reset applies reverse polarity with high reliability; read senses the mid-node voltage $$ V_{\mathrm mid} = V_{\mathrm read}\times \frac{R_{\mathrm ref}}{R_{\mathrm ref}+R_{\mathrm MTJ}} $$ under $V_{\mathrm read}} \approx 300\,\mathrm{mV}$ and compares it to $V_{\mathrm th} = (V_{\mathrm AP}+V_{\mathrm P})/2$. The reported energy is approximately $2.2\,\mathrm{pJ/bit}$, the entropy is approximately $0.999\,\mathrm{bits/bit}$, and the output passes NIST STS with no post-processing [2204.14204]. Taken together, these two magnetic implementations illustrate opposite roles for the management phase. In FeRh, management preserves a written state; in the MRAM TRNG, management intentionally erases it by resetting to a known starting point for the next cycle. ## 3. Operating-system enforcement in Application Read-Only Memory AROM defines a Write–Manage–Read loop for Long-term RAM in which LtRAM pages are read-only to applications and written only by the operating system during page migrations. The mechanism is PTE-level write protection enforced by copy-on-write. When an application store targets a virtual address mapped to an LtRAM page with its write bit cleared, the MMU raises a protection fault; the kernel allocates a fresh DRAM page, copies $4\,\mathrm{KiB}$ from the old LtRAM page to DRAM, updates the PTE to point to the DRAM page with `PROT_READ|WRITE`, flushes the TLB entry, frees the old LtRAM page back to the LtRAM zone’s free list, schedules a $4\,\mathrm{KiB}$ erase during idle, returns from the fault, and allows the CPU to re-execute the store into DRAM [2606.26138]. The management phase is carried largely by the kernel. A background migrator scans DRAM PTEs every interval $T$; if a page’s dirty bit remains clear for the entire scan window, it becomes a candidate for migration back to LtRAM. For each candidate, the token-bucket wear leveler grants permission, then the kernel allocates a fresh LtRAM page, erases its block if needed, copies $4\,\mathrm{KiB}$ from DRAM to LtRAM, updates the PTE to the LtRAM PFN with its write bit cleared, flushes the TLB, and frees the DRAM page. The DIMM-side controller is deliberately thin: read granularity is $64\,\mathrm B$, write granularity is $4\,\mathrm{KiB}$, per-block health metadata is exposed, and there is no on-DIMM AIT, no read-modify-write merge logic, and no opaque wear-level migrations [2606.26138]. The cost model centers on the probability $$ p = \Pr[\text{a random store hits an LtRAM page}], $$ with average access time $$ T = (1-p)L_{\text{read}} + p(L_{\text{mig}} + L_{\text{read}}) = L_{\text{read}} + pL_{\text{mig}}. $$ The supplied description sets post-migration DRAM reads at approximately $L_{\mathrm{DRAM}} \approx 80\,\mathrm{ns}$, projects AROM LtRAM reads at approximately $150$–$200\,\mathrm{ns}$, and contrasts this with Optane-style reads at approximately $305$–$374\,\mathrm{ns}$, identifying $\Delta L \approx L_{\mathrm{AIT\_lookup}} \approx 76\,\mathrm{ns}$ plus removal of RMW and tail latencies. In a read-mostly tier, where $\lambda_w \ll \lambda_r$, the text states that $p$ can be driven to $10^{-3}$ or smaller [2606.26138]. AROM is significant because it redefines the management stage as an OS responsibility rather than a hidden controller function. The loop therefore becomes both a memory-management policy and an interface contract: application writes are redirected into migration, while application reads are allowed to observe either DRAM-resident or LtRAM-resident data under a read-only invariant. ## 4. Decoupling in large-scale search engines In large-scale search engines, the Write–Manage–Read loop is presented as the central source of write-read contention: writes inject documents or updates, management performs segment merges, compactions, or structure builds, and reads traverse the current index structures to answer queries. In the dominant Lucene-derived model, those phases share CPU, memory, and I/O bandwidth, so management work inflates query latency and P99 variability. The survey identifies five principal decoupling patterns: node-level read-write separation, compute-storage separation, full in-memory indexing, log-structured write paths, and in-place partial updates [2605.01260]. Node-level separation moves indexing and merges to write nodes while search nodes load immutable snapshots; LinkedIn Galene is reported to achieve stable latency with freshness around $2$–$5$ minutes. Compute-storage separation places authoritative segments in shared object storage; Quickwit uses immutable $1$–$15\,\mathrm{GB}$ splits in S3, while Elasticsearch Serverless is described as using S3, multi-tiered caching, and batch-commit I/O reduction of $100\times$. Full in-memory indexing eliminates disk and page-cache interference at the expense of memory overhead $\alpha \approx 3$–$10\times$ raw data size; Algolia reports $P99 < 10\,\mathrm{ms}$, and Ximalaya is reported to reduce average query latency from $50\,\mathrm{ms}$ to $5\,\mathrm{ms}$. Log-structured paths append updates to Kafka or Pulsar and build optimized structures asynchronously; Milvus exposes growing segments searchable in under $1\,\mathrm s$. In-place partial updates store scalar attributes in forward arrays with $O(1)$ in-RAM writes and immediate visibility; Vespa Proton is the cited exemplar [2605.01260]. | System | Pattern | Freshness / latency / WAF | |---|---|---| | ES (shared-nothing) | Coupled | `1 s`, variable spikes, `10–30×` | | LinkedIn Galene | Node separation | `minutes`, `stable <50 ms`, `10–30×` | | Quickwit | Compute-storage separation | `minutes–hrs`, `60–200 ms`, `0` | | Algolia | In-memory | `≈1 s`, `<10 ms`, `0` | | Milvus | Log-structured | `<1 s (growing)`, `<50 ms`, `0` | | Vespa | In-place updates | `instant(attr.)`, `<5 ms`, `0 (attr)` | The survey’s unifying synthesis is ScaleSearch. It combines compute-storage separation with full in-memory search and dedicated write nodes, and adds per-field update routing through Kafka topics. For scalar fields in `CF-realtime`, each field $f$ receives its own topic $T_f$, and search nodes perform in-place updates `update_array[fieldID][docID] ← new_value` in $O(1)$ CPU and $O(1)$ memory per field, with immediate visibility and no merge. For `CF-text`, write nodes build immutable segments, upload them to S3, and search nodes poll, download, and merge them in RAM with $\mathrm{CPU}_{\mathrm{merge\_new}} \approx O(|S_{\mathrm new}|)$ and freshness approximated by upload latency plus poll interval, for example under $30\,\mathrm s$ [2605.01260]. The search-engine case gives the most explicit statement of why the intermediate phase matters. Management is both necessary and dangerous: without it, read cost grows; with it, contention grows unless the architecture isolates or reshapes the loop. ## 5. Explicit read-write memory for large language models RET-LLM and MemLLM-style MAuLLM instantiate the loop as an explicit memory interface around an LLM rather than as a latent parameter update. RET-LLM stores knowledge in triplets $\langle t_1,t_2,t_3\rangle$ inspired by Davidsonian semantics, with $t_1$ as subject, $t_2$ as predicate, and $t_3$ as object. Each element is embedded as a mean hidden representation, $$ h_{\mathrm{avg}}(t_i)=\frac{1}{|\mathrm{tokens}(t_i)|}\sum_{w\in \mathrm{tokens}(t_i)} h(w), $$ and inserted into a memory table together with metadata, while each slot representation is added to a locality-sensitive hashing index. Read queries specify one or more filled slots of $\langle q_1 \gg q_2 \gg q_3\rangle$; retrieval first attempts exact matching, then falls back to fuzzy match via LSH if needed, and ranks candidates by $$ \mathrm{score}(Q,m)=\sum_{i:q_i\neq\_}\cos(h_{\mathrm{avg}}(q_i),h_i(m)). $$ The joint training objective is $$ L_{\mathrm{total}} = L_{\mathrm{write}} + L_{\mathrm{read}}. $$ The design is explicitly described as scalable, aggregatable, updatable, and interpretable, with update policy implemented either as latest-wins overwrite or append [2305.14322]. The supplied MemLLM description presents a MemLLM-style system denoted MAuLLM. Its memory $\mathcal M$ is a set of relational triples $r=\langle e_s,t,e_o\rangle$ stored in entity and relation tables with fixed-dimensional embeddings produced by Contriever, and indexed by HNSW over all entity and relation embeddings. During the write phase, the model is fine-tuned so that an input sentence is converted into a token sequence of the form `({MEM_WRITE–> ... })`, with $$ L_{\mathrm{write}} = -\sum_{t=1}^{|y^\*|}\log P_\theta(y_t^\* \mid y^\*_{