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