summaryrefslogtreecommitdiffstats
path: root/Documentation/RCU/rcubarrier.txt
diff options
context:
space:
mode:
authorPaul E. McKenney <paulmck@linux.vnet.ibm.com>2012-05-07 16:43:30 -0400
committerPaul E. McKenney <paulmck@linux.vnet.ibm.com>2012-07-02 15:34:03 -0400
commit74d874e7bdc5b09cedcc7da0de44db25888eea10 (patch)
tree72cf891de767436eaba95e06e0a575f461297f8e /Documentation/RCU/rcubarrier.txt
parentcba6d0d64ee53772b285d0c0c288deefbeaf7775 (diff)
rcu: Update documentation to cover call_srcu() and srcu_barrier().
The advent of call_srcu() and srcu_barrier() obsoleted some of the documentation, so this commit brings that up to date. Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Diffstat (limited to 'Documentation/RCU/rcubarrier.txt')
-rw-r--r--Documentation/RCU/rcubarrier.txt15
1 files changed, 4 insertions, 11 deletions
diff --git a/Documentation/RCU/rcubarrier.txt b/Documentation/RCU/rcubarrier.txt
index e439a0edee22..38428c125135 100644
--- a/Documentation/RCU/rcubarrier.txt
+++ b/Documentation/RCU/rcubarrier.txt
@@ -79,8 +79,6 @@ complete. Pseudo-code using rcu_barrier() is as follows:
79 2. Execute rcu_barrier(). 79 2. Execute rcu_barrier().
80 3. Allow the module to be unloaded. 80 3. Allow the module to be unloaded.
81 81
82Quick Quiz #1: Why is there no srcu_barrier()?
83
84The rcutorture module makes use of rcu_barrier in its exit function 82The rcutorture module makes use of rcu_barrier in its exit function
85as follows: 83as follows:
86 84
@@ -162,7 +160,7 @@ for any pre-existing callbacks to complete.
162Then lines 55-62 print status and do operation-specific cleanup, and 160Then lines 55-62 print status and do operation-specific cleanup, and
163then return, permitting the module-unload operation to be completed. 161then return, permitting the module-unload operation to be completed.
164 162
165Quick Quiz #2: Is there any other situation where rcu_barrier() might 163Quick Quiz #1: Is there any other situation where rcu_barrier() might
166 be required? 164 be required?
167 165
168Your module might have additional complications. For example, if your 166Your module might have additional complications. For example, if your
@@ -242,7 +240,7 @@ reaches zero, as follows:
242 4 complete(&rcu_barrier_completion); 240 4 complete(&rcu_barrier_completion);
243 5 } 241 5 }
244 242
245Quick Quiz #3: What happens if CPU 0's rcu_barrier_func() executes 243Quick Quiz #2: What happens if CPU 0's rcu_barrier_func() executes
246 immediately (thus incrementing rcu_barrier_cpu_count to the 244 immediately (thus incrementing rcu_barrier_cpu_count to the
247 value one), but the other CPU's rcu_barrier_func() invocations 245 value one), but the other CPU's rcu_barrier_func() invocations
248 are delayed for a full grace period? Couldn't this result in 246 are delayed for a full grace period? Couldn't this result in
@@ -259,12 +257,7 @@ so that your module may be safely unloaded.
259 257
260Answers to Quick Quizzes 258Answers to Quick Quizzes
261 259
262Quick Quiz #1: Why is there no srcu_barrier()? 260Quick Quiz #1: Is there any other situation where rcu_barrier() might
263
264Answer: Since there is no call_srcu(), there can be no outstanding SRCU
265 callbacks. Therefore, there is no need to wait for them.
266
267Quick Quiz #2: Is there any other situation where rcu_barrier() might
268 be required? 261 be required?
269 262
270Answer: Interestingly enough, rcu_barrier() was not originally 263Answer: Interestingly enough, rcu_barrier() was not originally
@@ -278,7 +271,7 @@ Answer: Interestingly enough, rcu_barrier() was not originally
278 implementing rcutorture, and found that rcu_barrier() solves 271 implementing rcutorture, and found that rcu_barrier() solves
279 this problem as well. 272 this problem as well.
280 273
281Quick Quiz #3: What happens if CPU 0's rcu_barrier_func() executes 274Quick Quiz #2: What happens if CPU 0's rcu_barrier_func() executes
282 immediately (thus incrementing rcu_barrier_cpu_count to the 275 immediately (thus incrementing rcu_barrier_cpu_count to the
283 value one), but the other CPU's rcu_barrier_func() invocations 276 value one), but the other CPU's rcu_barrier_func() invocations
284 are delayed for a full grace period? Couldn't this result in 277 are delayed for a full grace period? Couldn't this result in