-----Original Message----- From: Rock Lee [mailto:rocklee_104@xxxxxxxxxxx] Sent: Tuesday, April 07, 2015 7:09 PM To: Jeff Haran Cc: kernelnewbies Subject: Re: maybe dumb question about RCU > > 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. > >This is the implementation of rcu_dereference(). It is a little old, but useful as well. > >#define rcu_dereference(p) ({ \ > typeof(p) _________p1 = ACCESS_ONCE(p); \ > smp_read_barrier_depends(); \ > (_________p1); \ > }) > >It uses memory barrier to guarantee the order of code execution. >rcu_read_lock() actually disables preemption, so writer has no chance to modify critical section in the rcu_read_lock()/rcu_read_unlock() pair. Thanks for getting back to me, Rock. Disabling preemption would prevent a writer on the same core as the reader from changing the pointer in the read critical section. But what happens if the writer is running on another core of a multi-core system? Seems like a writer on another core could still get in there and change the value of the pointer between the two rcu_dereference() calls in the reader. Jeff Haran _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
