maybe dumb question about RCU
Jeff Haran
Jeff.Haran at citrix.com
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
rcu_assign_pointer()/synchronize_rcu().
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;
rcu_read_lock();
a = rcu_dereference(global);
b = rcu_dereference(global);
rcu_read_unlock();
}
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:
247
248 p = rcu_dereference(head.next);
249 return p->data;
250
251 However, in this case, one could just as easily combine these
252 into one statement:
253
254 return rcu_dereference(head.next)->data;
255
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...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150407/840ba65e/attachment-0001.html
More information about the Kernelnewbies
mailing list