[ltt-dev] Userspace RCU library relicensed to LGPLv2.1
Mathieu Desnoyers
compudj at krystal.dyndns.org
Thu May 14 12:20:12 EDT 2009
* Jakub Jelinek (jakub at 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 at 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
More information about the lttng-dev
mailing list