Lines Matching refs:readers

32 Section 1, though most readers will profit by reading this section at
53 new versions of these data items), and can run concurrently with readers.
55 readers is the semantics of modern CPUs guarantee that readers will see
59 removal phase.  Because reclaiming data items can disrupt any readers
61 not start until readers no longer hold references to those data items.
65 reclamation phase until all readers active during the removal phase have
67 callback that is invoked after they finish.  Only readers that are active
75 	readers cannot gain a reference to it.
77 b.	Wait for all previous readers to complete their RCU read-side
80 c.	At this point, there cannot be any readers who hold references
85 The ability to wait until all readers are done allows RCU readers to
88 schemes, readers must use heavy-weight synchronization in order to
91 and must therefore exclude readers.  In contrast, RCU-based updaters
95 readers.  Concurrent RCU readers can then continue accessing the old
106 For example, RCU readers and updaters need not communicate at all,
107 but RCU provides implicit low-overhead communication between readers
111 that readers are not doing any sort of synchronization operations???
187 	readers are done, its implementation is key to RCU.  For RCU
373 	 * Uses rcu_assign_pointer() to ensure that concurrent readers
376 	 * Uses synchronize_rcu() to ensure that any readers that might
426 	This primitive protects concurrent readers from the updater,
474 	 * Uses rcu_assign_pointer() to ensure that concurrent readers
477 	 * Uses call_rcu() to ensure that any readers that might have
897 a.	Will readers need to block?  If so, you need SRCU.
899 b.	What about the -rt patchset?  If readers would need to block
900 	in an non-rt kernel, you need SRCU.  If readers would block
907 	or some other mechanism) as if they were explicit RCU readers?
962 		allows latency to "bleed" from readers to other
963 		readers through synchronize_rcu().  To see this,