Lines Matching refs:readers

51 Section 1, though most readers will profit by reading this section at
74 new versions of these data items), and can run concurrently with readers.
76 readers is the semantics of modern CPUs guarantee that readers will see
80 removal phase.  Because reclaiming data items can disrupt any readers
82 not start until readers no longer hold references to those data items.
86 reclamation phase until all readers active during the removal phase have
88 callback that is invoked after they finish.  Only readers that are active
96 	readers cannot gain a reference to it.
98 b.	Wait for all previous readers to complete their RCU read-side
101 c.	At this point, there cannot be any readers who hold references
106 The ability to wait until all readers are done allows RCU readers to
109 schemes, readers must use heavy-weight synchronization in order to
112 and must therefore exclude readers.  In contrast, RCU-based updaters
116 readers.  Concurrent RCU readers can then continue accessing the old
127 For example, RCU readers and updaters need not communicate at all,
128 but RCU provides implicit low-overhead communication between readers
132 that readers are not doing any sort of synchronization operations???
210 	readers are done, its implementation is key to RCU.  For RCU
327 	update-side code as well as by RCU readers, then an additional
422 	 * Uses rcu_assign_pointer() to ensure that concurrent readers
425 	 * Uses synchronize_rcu() to ensure that any readers that might
475 	This primitive protects concurrent readers from the updater,
524 	 * Uses rcu_assign_pointer() to ensure that concurrent readers
527 	 * Uses call_rcu() to ensure that any readers that might have
1088 a.	Will readers need to block?  If so, you need SRCU.
1090 b.	What about the -rt patchset?  If readers would need to block
1091 	in an non-rt kernel, you need SRCU.  If readers would block
1099 	or some other mechanism) as if they were explicit RCU readers?
1105 	attacks?  If so, you should disable softirq across your readers,
1160 		allows latency to "bleed" from readers to other
1161 		readers through synchronize_rcu().  To see this,