maybe dumb question about RCU

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

 

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux