Re: maybe dumb question about RCU

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies





[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux