maybe dumb question about RCU

Rock Lee rocklee_104 at outlook.com
Tue Apr 7 22:08:45 EDT 2015


>
> 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.



More information about the Kernelnewbies mailing list