On 25/03/07 09:28 +0100, Keir Fraser wrote:>On 24/3/07 19:22, "Mike D. Day" <ncmike@us.ibm.com> wrote:
>
>> Due to recent conversion of get_domain_by_id to use rcu techniques I
>> looked at the file xen/include/xen/rcupdate.h and noticed
>> rcu_read_lock is defined as:
>>
>> define rcu_read_lock(x) do { } while (0)
>>
>> as well as the corresponding unlock and other related macros.
>>
>> Apologies if this has already been answered, but when will the real
>> rcu code get into -unstable?
>
>The whole point of RCU is that read-side critical sections have no (or very
>little) synchronisation overhead. In Xen the rcu_read_[un]lock functions are
>only present to make the code clearer and to seome extent self documenting.
>On Linux they also disable involuntary preemption during the critical
>section (which is not needed on Xen, of course).
>
>So, in short, Xen already has a complete RCU implementation.
I see, the thing that threw me off was the sparse checker code in the
linux rcu_read_lock() implementation, as a comparison. However, it
doesn''t do anything either.
By the way, the linux implementation does not require a dummy lock
object:
#define rcu_read_lock() \
do { \
preempt_disable(); \
__acquire(RCU); \
} while(0)
This is better - in my opinion, it makes it clearer that the rcu reader
is not actually synchronizing on a spinlock.
I''d be happy to submit a patch for the reader lock/unlock macros.
Mike
--
Mike D. Day
IBM LTC
Cell: 919 412-3900
Sametime: ncmike@us.ibm.com AIM: ncmikeday Yahoo: ultra.runner
PGP key: http://www.ncultra.org/ncmike/pubkey.asc
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel