Editing Read-copy-update (section)

==Advantages and disadvantages==
The ability to wait until all readers are done allows RCU readers to use much lighter-weight synchronization&mdash;in some cases, absolutely no synchronization at all. In contrast, in more conventional lock-based schemes, readers must use heavy-weight synchronization in order to prevent an updater from deleting the data structure out from under them. The reason is that lock-based updaters typically update data in place and must therefore exclude readers. In contrast, RCU-based updaters typically take advantage of the fact that writes to single aligned pointers are atomic on modern CPUs, allowing atomic insertion, removal, and replacement of data in a linked structure without disrupting readers. Concurrent RCU readers can then continue accessing the old versions and can dispense with the atomic read-modify-write instructions, memory barriers, and cache misses that are so expensive on modern [[Symmetric multiprocessing|SMP]] computer systems, even in absence of lock contention.<ref>{{Cite journal
  | last1 = Hart
  | first1 = Thomas E.
  | last2 = McKenney
  | first2 = Paul E.
  | last3 = Demke Brown
  | first3 = Angela
  | last4 = Walpole
  | first4 = Jonathan
  | title = Performance of memory reclamation for lockless synchronization
  | journal = J. Parallel Distrib. Comput.
  | volume = 67
  | issue = 12
  | pages = 1270–1285
  | date = December 2007
  | doi=10.1016/j.jpdc.2007.04.010
  }}</ref><ref>{{cite web
  | last = McKenney
  | first = Paul E.
  | title = RCU part 2: Usage
  | publisher = [[Linux Weekly News]]
  | date = January 4, 2008
  | url = https://lwn.net/Articles/263130/
  | access-date = September 24, 2010 }}</ref>  The lightweight nature of RCU's read-side primitives provides additional advantages beyond excellent performance, scalability, and real-time response.  For example, they provide immunity to most [[deadlock (computer science)|deadlock]] and [[livelock]] conditions.<ref group=note>RCU-based deadlocks are still possible, for example by executing a statement that blocks until a grace period completes within an RCU read-side critical section.</ref>

Of course, RCU also has disadvantages.  For example, RCU is a specialized technique that works best in situations with mostly reads and few updates but is often less applicable to update-only workloads.  For another example, although the fact that RCU readers and updaters may execute concurrently is what enables the lightweight nature of RCU's read-side primitives, some algorithms may not be amenable to read/update concurrency.

Despite well over a decade of experience with RCU, the exact extent of its applicability is still a research topic.