You have a data structure read a million times per second and updated maybe ten times per minute — a routing table, a config map, a feature-flag registry. A mutex makes every read pay synchronization cost it almost never needs. Read-Copy-Update (RCU) flips the deal: readers pay nothing, writers do all the work.

The mechanic is simple. Readers dereference a pointer to the current version with no locks, no atomic operations beyond a plain load. A writer doesn't mutate in place — it copies the structure, modifies the copy, then atomically swaps the pointer to publish the new version. Old readers keep using the old version until they're done. Only after every pre-swap reader has finished can the old version be reclaimed — the famous "grace period."

Real example: the Linux kernel's routing table. Every packet looks up a route — millions per second on a busy box. Routes change on the scale of seconds. Linux uses RCU: packet-handling code reads the table lock-free, and route updates publish a new table via pointer swap. The reclamation happens after a grace period — typically after every CPU has performed a context switch, which proves no reader from before the swap is still running.

The rule of thumb: reach for RCU when your read:write ratio exceeds about 1000:1 and reads sit on a hot path. Below that ratio, the writer's copy cost (allocate + duplicate + reclaim) dominates and a reader-writer lock wins. Above it, eliminating the read-side barrier compounds into massive throughput gains.

What RCU costs you:

• Memory: two versions live simultaneously during the grace period — fine for a 4KB config, painful for a 4GB index.
• Writer complexity: writers serialize among themselves (usually with a mutex) and must wait out the grace period before freeing memory.
• Stale reads: a reader that started before the swap sees the old version. RCU gives you eventual consistency on the read path, not linearizability.
• Reclamation tracking: you need a way to know when all old readers are gone — quiescent-state detection, hazard pointers, or epoch-based reclamation.

Where you'll meet it in user space: userspace-rcu (liburcu) powers parts of LTTng and DPDK. Java's CopyOnWriteArrayList is RCU's spiritual cousin — same publish-by-swap idea, just without the deferred reclamation because the GC handles it. Functional languages get RCU semantics nearly for free: persistent data structures and atomic root-pointer swaps are RCU.

Don't reach for RCU when writes are frequent, the structure is huge, or you need readers to see the latest write immediately. Reach for it when reads vastly outnumber writes and contention on the read path is killing you.