Build fluency in the vocabulary of letting readers proceed lock-free while writers publish new versions via pointer swaps.
0 / 5 completed
1 / 5
A teammate explains that readers of a shared data structure never block, because writers publish a new version by atomically swapping a pointer, and the old version is only reclaimed once no reader could still be using it. What synchronization mechanism is being described?
Read-copy-update is exactly this: readers traverse the data structure without ever blocking or taking a lock, while a writer builds a new version and atomically swaps a pointer to publish it, and the old version is only freed once a grace period confirms no reader could still be traversing it. A hash collision is an unrelated hash-table concept about two keys sharing a bucket. This lock-free-reads-plus-deferred-reclamation approach is exactly why RCU is used in the Linux kernel for read-heavy data structures.
2 / 5
During a design review, the team adopts RCU for a routing table that is read millions of times per second but updated rarely, specifically so lookups never block on a writer publishing a new table. Which capability does this provide?
RCU here provides wait-free, lock-free reads even during concurrent updates, since readers only ever see a fully consistent old or new version via the atomically swapped pointer, with no locking overhead on the hot read path. A design where every lookup takes a reader-writer lock adds contention and cache-line bouncing exactly on the millions-of-lookups-per-second path this system needs to stay fast. This never-block-readers behavior is exactly why RCU is favored for read-dominated data structures like routing tables.
3 / 5
In a code review, a dev notices a read-heavy configuration cache takes a mutex on every lookup, even though updates to the configuration happen roughly once a day, instead of publishing new versions via an RCU-style pointer swap. What does this represent?
This is a missed RCU opportunity, since publishing new versions via an atomically swapped pointer would let lookups proceed lock-free instead of contending on a mutex for every read. A cache eviction policy is an unrelated concept about discarded cache entries. This mutex-per-lookup pattern is exactly the kind of unnecessary contention a reviewer flags once reads vastly outnumber writes.
4 / 5
An incident report shows lookup latency spiked under load because every reader contended on the same mutex protecting a rarely updated configuration table, even though no writer was active at the time. What practice would prevent this?
Switching the configuration table to an RCU-style scheme lets readers dereference an atomically published pointer without taking any lock, eliminating the reader-versus-reader contention entirely. Continuing to require every reader to take the same mutex regardless of how rarely the configuration table is actually updated is exactly what caused the latency spike described in this incident. This lock-free-read approach is the standard fix once mutex contention among readers is confirmed to be the bottleneck.
5 / 5
During a PR review, a teammate asks why the team reaches for RCU instead of a simple reader-writer lock, given that reader-writer locks are more familiar and simpler to reason about. What is the reasoning?
RCU trades deferred reclamation complexity for reads that never block or contend at all, while a reader-writer lock is simpler but still lets writers block readers and lets many readers contend on the same lock's internal state under heavy concurrency. This is exactly why RCU is favored for extremely read-heavy, rarely updated data structures, while a reader-writer lock remains acceptable when read concurrency is modest.