Skip to content

Commit a3fbf86

Browse files
committed
doc: Clarify rcu_assign_pointer() and rcu_dereference() ordering
This commit expands on the ordering properties of rcu_assign_pointer() and rcu_dereference(), outlining their constraints on CPUs and compilers. Reported-by: Rao Shoaib <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]>
1 parent 293d901 commit a3fbf86

File tree

1 file changed

+19
-11
lines changed

1 file changed

+19
-11
lines changed

Documentation/RCU/whatisRCU.rst

Lines changed: 19 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -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

Comments
 (0)