> 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 > Yeeees, rcu_read_lock() and rcu_read_unlock() calls never spin or block, nor do they prevent the writer from changing the value of the critical section concurrently. I am still confused about this part, sorry. I think this article will help, although my poor English hasn't make me fully understand it. http://lwn.net/Articles/262464/ _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
