Lines Matching refs:that

5 RCU (read-copy update) is a synchronization mechanism that can be thought
7 very low-overhead readers that are immune to deadlock, priority inversion,
12 This means that RCU writers are unaware of the presence of concurrent
13 readers, so that RCU updates to shared data must be undertaken quite
20 given that readers might well leave absolutely no trace of their
21 presence? There is a synchronize_rcu() primitive that blocks until all
33 another pointer to a function that may be invoked later to free that
75 callbacks to complete.  Please note that rcu_barrier() does -not- imply
88 the flavor of rcu_barrier() with that of call_rcu().  If your module
90 flavors of rcu_barrier() when unloading that module.  For example, if
166 Line 6 sets a global variable that prevents any RCU callbacks from
199 that RCU callbacks are never reordered once queued on one of the per-CPU
218 Line 3 verifies that the caller is in process context, and lines 5 and 10
219 use rcu_barrier_mutex to ensure that only one rcu_barrier() is using the
222 shown below. Note that the final "1" in on_each_cpu()'s argument list
223 ensures that all the calls to rcu_barrier_func() will have completed
244 which contains the struct rcu_head that needed for the later call to
272 so that your module may be safely unloaded.
284 	in response, so that Nikita could invoke it during the
288 	implementing rcutorture, and found that rcu_barrier() solves
297 Answer: This cannot happen. The reason is that on_each_cpu() has its last
311 	means that all CPUs have executed rcu_barrier_func() before