@@ -250,21 +250,25 @@ rcu_assign_pointer()
250
250
^^^^^^^^^^^^^^^^^^^^
251
251
void rcu_assign_pointer(p, typeof(p) v);
252
252
253
- Yes, rcu_assign_pointer() **is ** implemented as a macro, though it
254
- would be cool to be able to declare a function in this manner.
255
- (Compiler experts will no doubt disagree.)
253
+ Yes, rcu_assign_pointer() **is ** implemented as a macro, though
254
+ it would be cool to be able to declare a function in this manner.
255
+ (And there has been some discussion of adding overloaded functions
256
+ to the C language, so who knows?)
256
257
257
258
The updater uses this spatial macro to assign a new value to an
258
259
RCU-protected pointer, in order to safely communicate the change
259
260
in value from the updater to the reader. This is a spatial (as
260
261
opposed to temporal) macro. It does not evaluate to an rvalue,
261
- but it does execute any memory-barrier instructions required
262
- for a given CPU architecture. Its ordering properties are that
263
- of a store-release operation.
264
-
265
- Perhaps just as important, it serves to document (1) which
266
- pointers are protected by RCU and (2) the point at which a
267
- given structure becomes accessible to other CPUs. That said,
262
+ but it does provide any compiler directives and memory-barrier
263
+ instructions required for a given compile or CPU architecture.
264
+ Its ordering properties are that of a store-release operation,
265
+ that is, any prior loads and stores required to initialize the
266
+ structure are ordered before the store that publishes the pointer
267
+ to that structure.
268
+
269
+ Perhaps just as important, rcu_assign_pointer() serves to document
270
+ (1) which pointers are protected by RCU and (2) the point at which
271
+ a given structure becomes accessible to other CPUs. That said,
268
272
rcu_assign_pointer() is most frequently used indirectly, via
269
273
the _rcu list-manipulation primitives such as list_add_rcu().
270
274
@@ -283,7 +287,11 @@ rcu_dereference()
283
287
executes any needed memory-barrier instructions for a given
284
288
CPU architecture. Currently, only Alpha needs memory barriers
285
289
within rcu_dereference() -- on other CPUs, it compiles to a
286
- volatile load.
290
+ volatile load. However, no mainstream C compilers respect
291
+ address dependencies, so rcu_dereference() uses volatile casts,
292
+ which, in combination with the coding guidelines listed in
293
+ rcu_dereference.rst, prevent current compilers from breaking
294
+ these dependencies.
287
295
288
296
Common coding practice uses rcu_dereference() to copy an
289
297
RCU-protected pointer to a local variable, then dereferences
0 commit comments