-----Original Message-----
From: Rock Lee [mailto:[email protected]]
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
[email protected]
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
