diff options
author | Paul E. McKenney <paulmck@linux.vnet.ibm.com> | 2012-05-07 16:43:30 -0400 |
---|---|---|
committer | Paul E. McKenney <paulmck@linux.vnet.ibm.com> | 2012-07-02 15:34:03 -0400 |
commit | 74d874e7bdc5b09cedcc7da0de44db25888eea10 (patch) | |
tree | 72cf891de767436eaba95e06e0a575f461297f8e /Documentation/RCU/rcubarrier.txt | |
parent | cba6d0d64ee53772b285d0c0c288deefbeaf7775 (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.txt | 15 |
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 | ||
82 | Quick Quiz #1: Why is there no srcu_barrier()? | ||
83 | |||
84 | The rcutorture module makes use of rcu_barrier in its exit function | 82 | The rcutorture module makes use of rcu_barrier in its exit function |
85 | as follows: | 83 | as follows: |
86 | 84 | ||
@@ -162,7 +160,7 @@ for any pre-existing callbacks to complete. | |||
162 | Then lines 55-62 print status and do operation-specific cleanup, and | 160 | Then lines 55-62 print status and do operation-specific cleanup, and |
163 | then return, permitting the module-unload operation to be completed. | 161 | then return, permitting the module-unload operation to be completed. |
164 | 162 | ||
165 | Quick Quiz #2: Is there any other situation where rcu_barrier() might | 163 | Quick Quiz #1: Is there any other situation where rcu_barrier() might |
166 | be required? | 164 | be required? |
167 | 165 | ||
168 | Your module might have additional complications. For example, if your | 166 | Your 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 | ||
245 | Quick Quiz #3: What happens if CPU 0's rcu_barrier_func() executes | 243 | Quick 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 | ||
260 | Answers to Quick Quizzes | 258 | Answers to Quick Quizzes |
261 | 259 | ||
262 | Quick Quiz #1: Why is there no srcu_barrier()? | 260 | Quick Quiz #1: Is there any other situation where rcu_barrier() might |
263 | |||
264 | Answer: Since there is no call_srcu(), there can be no outstanding SRCU | ||
265 | callbacks. Therefore, there is no need to wait for them. | ||
266 | |||
267 | Quick Quiz #2: Is there any other situation where rcu_barrier() might | ||
268 | be required? | 261 | be required? |
269 | 262 | ||
270 | Answer: Interestingly enough, rcu_barrier() was not originally | 263 | Answer: 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 | ||
281 | Quick Quiz #3: What happens if CPU 0's rcu_barrier_func() executes | 274 | Quick 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 |