maybe dumb question about RCU

Jeff Haran Jeff.Haran at
Tue Apr 7 18:52:54 EDT 2015

Hi all,

I've been trying to understand the usage of RCU and am struggling a bit with one issue.
Let's say one intends to use "classic RCU" as described in whatisRCU.txt where readers use
sequences of rcu_read_lock(), rcu_dereference(), rcu_read_unlock) and updaters use

If one uses rcu_dereference() to access an RCU protect pointer twice within the same rcu
read locked critical section, is it guaranteed that the pointers returned by rcu_dereference()
will point to the same block of memory?

For instance, in the following code (trying make this as simple as possible even if it does nothing useful):

char *global;
char x[1];
char y[1];

void reader(void)
                char *a;
                char *b;

                a = rcu_dereference(global);
                b = rcu_dereference(global);

void updater(void)
                rcu_assign_pointer(global, x);
                rcu_assign_pointer(global, y);

Following the second call to rcu_deference() in reader(), is it guaranteed that a and b will be
equal (either both equal to x or both equal y)? Or is it possible what a will equal x and b will equal y?

whatisRCU.txt seems to imply that though this is bad practice because its wasteful, both calls
to rcu_dereference() will return the same pointer:

"228 rcu_dereference()
244         Common coding practice uses rcu_dereference() to copy an
245         RCU-protected pointer to a local variable, then dereferences
246         this local variable, for example as follows:
248                 p = rcu_dereference(;
249                 return p->data;
251         However, in this case, one could just as easily combine these
252         into one statement:
254                 return rcu_dereference(>data;
256         If you are going to be fetching multiple fields from the
257         RCU-protected structure, using the local variable is of
258         course preferred.  Repeated rcu_dereference() calls look
259         ugly and incur unnecessary overhead on Alpha CPUs."

>From lines 256 to 259 I conclude that reader()'s code is considered ugly and wasteful,
but a will always equal b.

But looking at how rcu_dereference() and rcu_assign_pointer() are implemented, I'm having a
hard time seeing how reader() would always see a and b equal.

Thanks in advance,

Jeff Haran

-------------- next part --------------
An HTML attachment was scrubbed...

More information about the Kernelnewbies mailing list