Read-Copy Update, commonly called RCU, is a synchronization family used throughout the Linux kernel for data that is read frequently and changed less often. Its central move is to separate two events that ordinary locking often treats as one: removing an object from a shared structure and reclaiming the memory that stored it.
A writer can publish a new state or unlink an old object while readers continue through read-side critical sections. The old storage remains valid until the kernel has established that every reader that could have observed the old reference has passed through a quiescent state. That interval is an RCU grace period.
Removal does not make storage immediately disposable
Consider a shared pointer to an object. A reader can load the pointer and begin using the object while a writer concurrently replaces the shared pointer.
reader writer
load pointer -> object A
publish object B
use object A
object A still retained
exit RCU read section
grace period completes
reclaim object AAfter object B is published, new readers can follow the new pointer. A reader that already obtained object A may still be active, so freeing A at publication time could turn a valid read into a use-after-free.
RCU therefore treats logical removal and physical reclamation as distinct operations. The shared structure can move forward before the retired storage is returned to an allocator.
Read-side sections establish a lifetime boundary
Kernel code marks RCU read-side critical sections with APIs appropriate to the RCU flavor in use. Within the relevant rules, a reader can dereference an RCU-protected pointer and rely on the referenced object remaining alive for the required interval.
This does not make every field immutable. Writers still need a valid publication protocol, and readers need the matching access primitives when concurrent updates are possible. RCU protects a lifetime and visibility pattern; it is not a blanket replacement for all synchronization.
The practical benefit is that common read paths often avoid taking a contended writer-owned lock. That can be valuable for routing tables, lookup structures, credentials, networking state, and other kernel data reached by many CPUs.
A grace period accounts for pre-existing readers
A grace period is not simply a fixed delay measured by a timer. Its completion represents an ordering condition: readers that could have retained references from before the update are no longer in read-side critical sections that can use those references.
The exact machinery depends on the RCU implementation and kernel configuration. Linux tracks quiescent states and coordinates CPUs so grace-period progress can be established without requiring every reader to increment and decrement one global reference counter.
This distinction matters. Sleeping for an arbitrary duration cannot prove that a stalled or preempted reader has stopped using an object. Grace-period detection is tied to execution state rather than elapsed wall-clock time.
Publication needs ordering as well as pointer replacement
Concurrent readers must not observe a newly published pointer while seeing incompletely initialized state behind it. Linux provides RCU publication and dereference primitives that carry the ordering semantics required by the supported pattern.
A typical writer prepares an object before making its pointer reachable. A matching reader obtains that pointer through the RCU access path. The relevant barriers and compiler constraints prevent the publication sequence from being reduced to an unsafe plain-pointer convention.
The details are architecture-sensitive, so kernel code relies on the RCU APIs instead of embedding assumptions about a particular CPU memory model.
Reclamation can be deferred in different forms
A writer that must wait synchronously can use an RCU synchronization operation suited to its context. Other paths can queue deferred work so reclamation happens after a grace period without blocking the updating task for the full interval.
That choice affects latency and resource pressure. Synchronous waiting keeps control flow simple but can delay the writer. Callback-based reclamation lets the writer continue, while retired objects occupy memory until their callbacks become eligible to run.
Heavy update rates can therefore create a backlog of pending reclamation even when reader-side execution is efficient. RCU moves part of the synchronization cost away from the read path; it does not erase the cost.
RCU does not serialize competing writers by itself
Two writers modifying the same structure can still require a lock, atomic operation, or another update-side protocol. RCU primarily supplies safe publication and delayed reclamation patterns for readers operating concurrently with updates.
For example, a linked structure may use a lock to serialize insertion and removal while readers traverse it under RCU protection. The writer lock prevents conflicting structural edits; the grace period protects readers from storage disappearing beneath an older traversal.
Treating those jobs separately makes the design easier to reason about: update serialization controls writer-versus-writer races, while RCU lifetime rules cover reader-versus-reclamation races.
Long readers postpone memory reuse
A reader that remains in an RCU read-side critical section for too long can delay the point at which retired objects become reclaimable. The consequences differ across RCU flavors and kernel configurations, but the general pressure is the same: reclamation progress depends on relevant old readers ceasing to qualify as active users of the retired state.
For systems with frequent updates, this can turn reader duration into a memory-management concern. Short read-side sections keep the lifetime boundary tight and allow deferred callbacks to advance more predictably.
Debugging RCU problems therefore often involves more than looking for a conventional lock cycle. Stalls, callback backlog, incorrect pointer access, and premature freeing can all point to violations of the intended lifetime protocol.
Grace periods make old references safe to outlive publication
RCU permits a shared structure to expose new state without forcing every current reader to stop at the update boundary. The writer removes or replaces reachability first, then reclamation waits until pre-existing readers can no longer rely on the retired object.
That separation is the core engineering trade. Read paths can remain lightweight, while update paths carry publication ordering, grace-period coordination, and deferred memory reclamation. Used with the matching kernel APIs, the result is a concurrency model built around safe overlap rather than immediate exclusion.