Read-copy-update principles

Consider a published pointer to an immutable configuration. A writer allocates and initializes a new configuration, then publishes that pointer using the matching RCU API. A reader enters a read-side critical section and obtains the pointer using the matching dereference API. Publication ordering prevents that reader from observing an incompletely initialized replacement. A reader that already obtained the old pointer may continue using the old configuration within its protected section; publication does not abruptly invalidate the earlier version.

After removing the old object from the reachable structure, the writer requests a grace period before reclaiming it. The grace-period mechanism establishes that relevant pre-existing read-side critical sections have completed. It does not require every future reader to stop arriving, nor a global instant at which no reader exists. It is also not a fixed sleep duration. The actual implementation detects progress and may conservatively wait longer than the latest old reader’s completion; the application must wait for its API’s completion signal.

Two writers can still race while deriving and publishing replacements. RCU does not automatically serialize those updates, prevent lost changes, or make arbitrary in-place field mutation safe. A writer mutex or another proven update protocol commonly handles that responsibility. Similarly, a reader must not save a raw object pointer, exit its read-side critical section, and use the pointer later. Copy the needed value while protected or obtain a separately managed ownership reference that explicitly extends the lifetime.

Choose the RCU flavor before reasoning about allowed blocking. Ordinary kernel RCU read-side rules differ from SRCU and other specialized variants; an example written for one is not an implementation recipe for another. The synchronous synchronize_rcu path waits for a grace period. The asynchronous call_rcu path schedules a callback after an appropriate grace period, but may accumulate deferred callbacks if writers run ahead. Callback context and allocation rules also matter. Faster publication does not imply that reclamation backlog is bounded.

An application should state what a read promises. Obtaining one pointer and reading immutable fields from that object gives a coherent version of those fields. Independently loading two changing pointers may combine versions unless the data structure supplies a stronger snapshot mechanism. RCU alone does not turn a multi-object operation into a transaction. Ask whether a stale routing decision is acceptable, whether related fields belong in the same replacement object, and how long a reader is permitted to retain its protected access.

Long readers and rapid replacement can increase retained memory. Rate times grace-period delay gives a rough steady-flow estimate, excluding bursts, allocator overhead, and callback execution delay. Use the queue lab as a backlog analogy, with arrival representing version retirement and service reclamation. For each separate fixed-rate run choose Reset, explicitly set both rates, predict, then Play or Step. Compare arrival two and service three with a fresh Reset followed by arrival two and service one; the second grows from four initial versions. Editing a rate retains elapsed time and recomputes the model from its initial four versions, rather than preserving a live backlog through a service change. The fluid model does not implement RCU or detect a grace period. A displayed stable queue is therefore no evidence that a reader’s pointer is safe to free.