docs/devel/rcu.rst

18 sections of code with "critical sections", and the update side will wait
19 for the execution of all *currently running* critical sections before
22 The key point here is that only the currently running critical sections
23 are waited for; critical sections that are started **after** the beginning
34 removal has completed, a critical section will not be able to access
35 the old data.  Therefore, critical sections that begin after removal
36 do not matter; as soon as all previous critical sections have finished,
54 Note how thread 3 is still executing its critical section when thread 2
57 that critical section.
67         entering an RCU read-side critical section.
71         exiting an RCU read-side critical section.  Note that RCU
72         read-side critical sections may be nested and/or overlapping.
75         Blocks until all pre-existing RCU read-side critical sections
87         read-side critical sections on all threads have completed.  This
132         ``qatomic_rcu_read`` assumes that whenever a single RCU critical
135         case when using RCU, because read-side critical sections typically
140         RCU read-side critical sections must use ``qatomic_rcu_read()`` to
144         Furthermore, RCU read-side critical sections should traverse the
160         order as reads in the RCU read-side critical sections (or if
198 - Waiting on a mutex is possible, though discouraged, within an RCU critical
201   critical section to become an updater.
243 read-side critical section in progress, the RCU read-side primitives
252 The RCU read-side critical section ensures that the value of ``p`` remains
254 a reference to ``p`` that is later released when the critical section ends.
264 If the processing cannot be done purely within the critical section, it
326 out of the write-side critical section.