Re: tr1::shared_ptr and v3's atomic ops

[Richard Henderson <rth at redhat dot com>]

On Thu, Mar 24, 2005 at 11:44:57AM -0600, Benjamin Kosnik wrote:
> I think we need this functionality. I'm not quite sure the best way to
> go about this. For some time we've been kicking around the idea that
> the atomic ops should just be compiler builtins.
> 
> Thus, maybe something like:
> 
> __builtin_atomic_compare_and_swap
> __builtin_atomic_add
> __builtin_atomic_exchange_and_add
> 
> Jason, Richard: any thought on this? Maybe this isn't the best time to
> do this, and v3 should just re-add exchange_and_add to atomicity.h?

It's probably not the best time.  I certainly would like to have us 
implement the interface in <ia64intrin.h> generically across all
architectures[*].  The api seems well thought out, and I know that at
least SGI implemented these builtins for both ia64 and mips.

I'm not sure what kind of timeline there would be on getting these
builtins though.

OTOH, it would certainly be possible to steal code from the linux
kernel and/or glibc to implement the aforementioned interface with
plain old inline assembly.  That probably wouldn't take more than a
couple of hours per target.  So it wouldn't be impossible to write
to the interface now, and have that be replaced by compiler builtins
when they become available.

> > 2) Do the v3 atomic ops give any guarantees about memory synchronisation
> > on systems with relaxed memory visibility rules ?  Peter Dimov has asked
> > on the Boost list for help regarding v3's atomic ops, as he wants to
> > have a lock-free shared_ptr on unix as well as on Windows:
> > http://lists.boost.org/MailArchives/boost/msg81481.php
> 
> Jason is probably the best person to ask about this.

The ia64intrin.h interface certainly does give such guarantees.


r~


[*] Well, those that can perform them at all without resorting to
spinlocks.  So true 80386 is out for many of them, as is Sparc prior
to v9.  I'm sure there are other small architectures that just can't
hack it either.