Le Tue, Jun 04, 2024 at 03:21:55PM -0700, Paul E. McKenney a écrit : > 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 <rao.shoaib@xxxxxxxxxx> > Signed-off-by: Paul E. McKenney <paulmck@xxxxxxxxxx> > --- > Documentation/RCU/whatisRCU.rst | 30 +++++++++++++++++++----------- > 1 file changed, 19 insertions(+), 11 deletions(-) > > diff --git a/Documentation/RCU/whatisRCU.rst b/Documentation/RCU/whatisRCU.rst > index 94838c65c7d97..d585a5490aeec 100644 > --- a/Documentation/RCU/whatisRCU.rst > +++ b/Documentation/RCU/whatisRCU.rst > @@ -250,21 +250,25 @@ rcu_assign_pointer() > ^^^^^^^^^^^^^^^^^^^^ > void rcu_assign_pointer(p, typeof(p) v); > > - Yes, rcu_assign_pointer() **is** implemented as a macro, though it > - would be cool to be able to declare a function in this manner. > - (Compiler experts will no doubt disagree.) > + Yes, rcu_assign_pointer() **is** implemented as a macro, though > + it would be cool to be able to declare a function in this manner. > + (And there has been some discussion of adding overloaded functions > + to the C language, so who knows?) > > The updater uses this spatial macro to assign a new value to an > RCU-protected pointer, in order to safely communicate the change > in value from the updater to the reader. This is a spatial (as > opposed to temporal) macro. It does not evaluate to an rvalue, > - but it does execute any memory-barrier instructions required > - for a given CPU architecture. Its ordering properties are that > - of a store-release operation. > - > - Perhaps just as important, it serves to document (1) which > - pointers are protected by RCU and (2) the point at which a > - given structure becomes accessible to other CPUs. That said, > + but it does provide any compiler directives and memory-barrier > + instructions required for a given compile or CPU architecture. > + Its ordering properties are that of a store-release operation, > + that is, any prior loads and stores required to initialize the > + structure are ordered before the store that publishes the pointer > + to that structure. About that, why rcu_dereference() isn't a matching load-acquire? Thanks.
