Read, Copy, Update, then what? RCU for non-kernel programmers
summary
RCU implements a one-writer RCU publishing protocol: readers do atomic acquire-loads and writers prepare copies then atomically swap the root, deferring frees into generation-tagged garbage queues and calling synchronize-RCU to wait for exiting readers. A user-space implementation with per-generation refcounts and per-thread counters shows RCU stays within a few percent of uncontended reads (experiment: about one write per 100 reads), while POSIX read–write locks and atomic-shared-pointer lists are measurably slower.
AI-written summary · about
chapters (27)
- 0:00Introduction
- 0:37Why RCU
- 5:46Not a fair comparison
- 9:15Atomic Writes
- 12:58CopyOnWrite
- 15:51OneThread
- 25:18What is an RCU
- 27:51Writers
- 29:30Readers
- 31:59Concept
- 34:53Function names
- 35:39Universal RCU
- 38:34Userspace
- 39:32Generation
- 43:23Implementation
- 44:53Sequential Consistency
- 46:10Synchronized RC
- 47:43Minimize ReadLock
- 49:24One possible solution
- 52:30Deferred deferred deletion
- 53:15Updates vs cleanup
- 54:48Performance
- 55:55Stress Test
- 56:36ForceReclaim
- 57:10Reuse
- 58:22When
- 59:17Hazard pointers
related talks
28mRevisit Multi-Reader Synchronizations for Scalable Applications
17mExploring a real life RCU use case for Rust
19mVerifying General-Purpose RCU for Reclamation in Relaxed Memory Separation Logic
55m“A lock-free concurrency toolkit for deferred reclamation and optimistic speculation"
43mC++ Atomics...
30mSo you want to torture RCU?
01h 06m“How to make your data structures wait-free for reads"
58m“The Landscape and Exciting New Future of Safe Reclamation for High Performance”