This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [ltt-dev] Userspace RCU library relicensed to LGPLv2.1
- From: Mathieu Desnoyers <compudj at krystal dot dyndns dot org>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: "Paul E. McKenney" <paulmck at linux dot vnet dot ibm dot com>, steven dot bennett at us dot ibm dot com, zbrown at tumblerings dot org, Jonathan Corbet <corbet at lwn dot net>, tech-board <tech-board at lists dot linux-foundation dot org>, ltt-dev at lists dot casi dot polymtl dot ca, Dominique Toupin <dominique dot toupin at ericsson dot com>, Evgeniy Polyakov <zbr at ioremap dot net>, Jake Edge <jake at lwn dot net>, Jan Blunck <jblunck at suse dot de>, libc-alpha at sources dot redhat dot com
- Date: Thu, 14 May 2009 12:20:12 -0400
- Subject: Re: [ltt-dev] Userspace RCU library relicensed to LGPLv2.1
- References: <20090513204308.GA27340@Krystal> <20090514092738.GO17988@bolzano.suse.de> <20090514130639.GD21241@Krystal> <20090514134622.GT17988@bolzano.suse.de> <20090514140346.GB23866@Krystal> <20090514155730.GN16681@sunsite.ms.mff.cuni.cz>
* Jakub Jelinek (jakub@redhat.com) wrote:
> On Thu, May 14, 2009 at 10:03:46AM -0400, Mathieu Desnoyers wrote:
> > The gcc-friendly solution would be to add a
> >
> > type __sync_val_xchg(type *ptr, type value)
> >
> > primitive to gcc atomic ops.
>
> How would that be different from __sync_lock_test_and_set?
It would be required to accept values other than a "1" immediate value
on all architectures.
> The only drawback is that __sync_lock_test_and_set? is not a full barrier,
> but only an acquire barrier (though on i386/x86_64 and a bunch of other
> targets it makes no difference at all).
>
Actually, unless I'm mistakened, the xchg() we need for the
rcu_xchg_pointer() primitive clearly does not need release semantic
because we always have :
ptrold = xchg(&rcuptr, newptr);
synchronize_rcu(); /* with full memory barriers */
free(oldptr); /* or reuse oldptr... */
As you see, the memory barriers within the synchronize_rcu() act as a
release barrier.
I would also tend to think that in this case, the acquire barrier is not
even needed, because we don't care if instructions following the xchg,
which does not have any data dependency on ptrold are reordered before
the xchg execution, because any operation that would have an undesirable
side-effect on the content pointed to by ptrold are required to appear
after synchronize_rcu() to ensure a grace period has passed.
Outside of the synchronize_rcu() scope, I'm not convinced that having a
release semantic on xchg() is useful at all. This is why I implemented
my xchg() with acquire, but not release semantic. Do you have a
particular use-case in mind where release semantic is useful for
xchg() ?
Mathieu
> Jakub
>
> _______________________________________________
> ltt-dev mailing list
> ltt-dev@lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
>
--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68