How Does Read-Copy-Update Let Readers Avoid Locks?

Read-Copy-Update Explainer

Read-copy-update, usually shortened to RCU, is a synchronization technique for shared data that is read far more often than it is changed. Its defining idea is that readers should usually be able to follow an existing pointer without taking a conventional lock. A writer prepares a new version or removes an object from the structure, publishes the changed pointer, and postpones destruction of the old object. Readers that began before the change can finish using the old version, while later readers find the new one. This division between changing visibility and reclaiming memory is what makes RCU fast for read-heavy paths.

An update normally has three conceptual steps. First, the writer creates or edits data in a way that is not yet visible to readers. Second, it publishes a pointer to the new state or removes the pointer that made an old object reachable. The publication must use the memory-ordering operations required by the implementation so readers never observe a pointer before the object behind it is fully initialized. Third, the writer waits for a grace period before freeing the displaced object. A grace period ends only after every reader that could still hold a reference from before the update has passed through a state where that reference can no longer be in use.

Readers mark the portion of code in which an RCU-protected reference may be used. In the Linux kernel, these read-side critical sections begin and end with RCU primitives whose cost can be much lower than acquiring a shared lock. A reader obtains the current protected pointer, examines the object, and releases the read-side protection. It does not promise that the object is the newest version; it promises that the object will remain valid for the permitted lifetime. This distinction is crucial. RCU offers safe access to a coherent published version, not an automatic transaction that freezes an entire data structure against every concurrent change.

Consider a routing table represented by linked nodes. To remove one route, a writer can redirect the relevant link so new lookups skip that node. A lookup that already reached the node may still be reading it, so immediate deallocation would create a use-after-free bug. The writer instead schedules reclamation after an RCU grace period. Once all pre-existing readers have completed, no qualifying reader can still possess the old reference, and the memory may be reused. Insertions and replacements follow the same principle: build the new node privately, publish it atomically, and retire the old state later.

The benefit comes with costs that shift toward writers and memory management. Writers may still need a mutex or another mechanism to serialize with one another, because RCU by itself does not prevent two updates from conflicting. Old versions occupy memory until reclamation is safe, and a stalled reader can delay that point. Developers must use the correct pointer-access and publication primitives, respect the allowed lifetime of references, and understand which events count as quiescent states for the chosen RCU variant. Debugging is difficult because a missing grace period or an escaped pointer may fail only under rare timing.

RCU is therefore not a universal replacement for locks. It is well suited to operating-system tables, caches, registries, and other structures with frequent short reads and relatively infrequent updates. It is less attractive when readers need a multi-object snapshot, updates dominate the workload, or old versions are expensive to retain. Healthy designs also keep read-side sections short and expose monitoring for callbacks or retired objects that are waiting too long. The practical achievement of RCU is narrower and powerful: it lets a system keep read paths extremely light while preserving memory safety through deliberate publication, grace-period tracking, and delayed reclamation.