@@ -250,21 +250,25 @@ rcu_assign_pointer()
250250^^^^^^^^^^^^^^^^^^^^
251251 void rcu_assign_pointer(p, typeof(p) v);
252252
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?)
256257
257258 The updater uses this spatial macro to assign a new value to an
258259 RCU-protected pointer, in order to safely communicate the change
259260 in value from the updater to the reader. This is a spatial (as
260261 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,
268272 rcu_assign_pointer() is most frequently used indirectly, via
269273 the _rcu list-manipulation primitives such as list_add_rcu().
270274
@@ -283,7 +287,11 @@ rcu_dereference()
283287 executes any needed memory-barrier instructions for a given
284288 CPU architecture. Currently, only Alpha needs memory barriers
285289 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.
287295
288296 Common coding practice uses rcu_dereference() to copy an
289297 RCU-protected pointer to a local variable, then dereferences
0 commit comments