Lines Matching full:readers

56 Section 1, though most readers will profit by reading this section at
79 new versions of these data items), and can run concurrently with readers.
81 readers is the semantics of modern CPUs guarantee that readers will see
85 removal phase.  Because reclaiming data items can disrupt any readers
87 not start until readers no longer hold references to those data items.
91 reclamation phase until all readers active during the removal phase have
93 callback that is invoked after they finish.  Only readers that are active
101 	readers cannot gain a reference to it.
103 b.	Wait for all previous readers to complete their RCU read-side
106 c.	At this point, there cannot be any readers who hold references
111 The ability to wait until all readers are done allows RCU readers to
114 schemes, readers must use heavy-weight synchronization in order to
117 and must therefore exclude readers.  In contrast, RCU-based updaters
121 readers.  Concurrent RCU readers can then continue accessing the old
132 For example, RCU readers and updaters need not communicate at all,
133 but RCU provides implicit low-overhead communication between readers
137 that readers are not doing any sort of synchronization operations???
228 	readers are done, its implementation is key to RCU.  For RCU
356 	update-side code as well as by RCU readers, then an additional
456 	 * Uses rcu_assign_pointer() to ensure that concurrent readers
459 	 * Uses synchronize_rcu() to ensure that any readers that might
509 	This primitive protects concurrent readers from the updater,
558 	 * Uses rcu_assign_pointer() to ensure that concurrent readers
561 	 * Uses call_rcu() to ensure that any readers that might have
1155 a.	Will readers need to block?  If so, you need SRCU.
1157 b.	Will readers need to block and are you doing tracing, for
1161 c.	What about the -rt patchset?  If readers would need to block in
1162 	an non-rt kernel, you need SRCU.  If readers would block when
1170 	or some other mechanism) as if they were explicit RCU readers?
1171 	If so, RCU-sched readers are the only choice that will work
1178 	If so, you should disable softirq across your readers, for
1235 		allows latency to "bleed" from readers to other
1236 		readers through synchronize_rcu().  To see this,