maybe dumb question about RCU

[Rock Lee]

> From: Rock Lee [mailto:rocklee_104 at outlook.com]
> 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/