Read-Copy-Update and the Linux Kernel’s Read-Mostly Synchronization Technique
Read-copy-update reorganized synchronization around cheap readers, versioned updates, and delayed reclamation, making read-mostly kernel data structures scale without conventional reader locking.
Traditional locking makes readers participate in synchronization even when they only observe data
Reader-writer locks improve on exclusive mutexes by allowing multiple readers to proceed together, but readers still execute synchronization operations and may contend on shared lock state. On large multiprocessors, that overhead can become significant when reads vastly outnumber updates. Paul McKenney and John Slingwine developed read-copy-update, or RCU, around a different question: can readers avoid most coordination if updaters take responsibility for preserving old data until readers are finished?[1]
RCU optimizes for asymmetry
It is especially attractive when reads are extremely frequent, updates are less common, and readers can tolerate observing either the old or the new version of a data structure.
The core idea separates changing visibility from reclaiming memory
Linux documentation describes RCU updates as two phases: removal and reclamation. An updater first changes references so new readers stop discovering an obsolete object, often by linking in a replacement. It does not immediately free the old object. Instead, reclamation waits until a grace period has passed and all readers that could still hold the old reference have completed.[2] This separation allows reads to overlap with updates without placing a traditional lock acquisition on every read path.
Grace periods turn execution history into a synchronization mechanism
The 1998 RCU paper described using execution history to determine when data can be safely reclaimed.[1] Linux implementations exploit events that prove pre-existing read-side critical sections can no longer be active. The exact mechanisms vary by RCU flavor and kernel configuration, but the conceptual point is stable: reclamation is deferred until the system knows that readers from the previous generation are gone. The history of thread execution substitutes for explicit reference tracking on every read.
Readers and reclaimers coordinate indirectly
RCU’s unusual performance comes from avoiding a shared counter or lock update on the hottest read path. The burden moves to grace-period detection and deferred cleanup.
Read-side operations can be extraordinarily cheap
The Linux RCU documentation notes that readers need not acquire locks, perform atomic instructions, write shared memory, or—on most CPUs—execute memory barriers in the classic RCU read-side path.[3] This makes RCU valuable for kernel structures such as routing tables, file-system caches, and networking data that are consulted constantly. The optimization is architectural: rather than making a lock faster, RCU changes the synchronization contract so readers perform less work.
Updaters pay complexity to keep readers simple
RCU is not a universal replacement for locks. Updaters must create or modify versions safely, publish pointers with appropriate memory-ordering operations, and delay destruction until a grace period completes. If multiple writers can conflict, they may still need locking among themselves. The technique therefore shifts cost from the common read path into update logic and lifecycle management. Linux’s core RCU APIs—such as rcu_dereference(), rcu_assign_pointer(), synchronize_rcu(), and call_rcu()—make these responsibilities explicit.[2]
Memory reclamation is the hard boundary
A reader can safely observe an old version only while that version still exists. Reclamation, not merely pointer replacement, is what turns concurrent access into a lifetime problem.
Linux made RCU a production technique rather than only a research idea
RCU was integrated into Linux during the 2.5 development series and became a key scaling mechanism for read-mostly kernel paths.[2] Work on Linux also forced the technique to coexist with preemption, real-time scheduling, hot-plugged CPUs, and many workload patterns. Research on making RCU safe for deep sub-millisecond real-time response illustrates how a synchronization method must evolve once it becomes operating-system infrastructure.[4]
RCU influenced how programmers think about nonblocking read-mostly structures
McKenney’s broader parallel-programming text treats RCU as part of a family of techniques for shared-memory scalability and emphasizes choosing synchronization according to workload structure rather than habit.[5] The lesson extends beyond the Linux kernel. User-space RCU implementations, epoch-based reclamation, hazard pointers, and persistent immutable data structures all explore related tradeoffs between cheap access, versioning, and safe reclamation.
The design question becomes who should pay
RCU is compelling when millions of readers can be made nearly free by asking comparatively rare updaters and reclaimers to do more sophisticated work.
Why RCU belongs in the history of concurrency
RCU belongs in concurrency history because it challenged the assumption that all participants must synchronize symmetrically. McKenney and Slingwine reframed the problem around read-mostly workloads, Linux turned the idea into a widely deployed kernel primitive, and decades of engineering expanded it across processor counts and real-time requirements.[1][4]
The technique also made memory lifetime central to synchronization. A pointer can be removed from a data structure long before its storage is safe to reuse, and correctness depends on distinguishing those moments. That separation is now a recurring idea in lock-free and low-lock data structures.
RCU’s success came from matching the mechanism to the workload. When reads dominate, avoiding reader-side writes and lock contention can matter more than making updates simple. The Linux kernel’s adoption of RCU demonstrated that this asymmetry could scale from research papers to some of the most performance-sensitive shared data structures in production computing.
Works Cited
- 01
- 02Linux Kernel Documentation — What is RCU? kernel.org
- 03Linux Kernel Documentation — RCU Concepts docs.kernel.org
- 04
- 05
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.
Submit a research lead