Fw: [patch] Make std::tr1::shared_ptr thread-safe.

[Alexander Terekhov]

On Apr 1, 2005 4:51 PM, Paolo Carlini <pcarlini@suse.de> wrote:
> Alexander Terekhov wrote:
> 
> >It is about msync semantics of exchange_and_add(). If you rely on
> >msync semantics which it doesn't provide, your code is broken. If it
> >is guaranteed to provide "fully-fenced" semantics (mimicking Intel's
> >__sync_fetch_and_add()), then (apart from unneeded overhead) you're
> >fine.
> >
> >
> Ok. Therefore, can well be the case that the port maintainers that
> provided (inline assembly ) implementations of exchange_and_add for the
> various archs chose to provide "fully-fenced" semantics, right?

That's certainly not impossible, I suppose. Where is it documented? Is it
subject to change at any time without notice?

> 
> Maybe you can volunteer to check a few of those implementations? Maybe
> ia64? For your convenience, reads, simply (exploiting built-ins in such
> case):
> 
> namespace __gnu_cxx
> {
>  _Atomic_word
>  __attribute__ ((__unused__))
>  __exchange_and_add(volatile _Atomic_word* __mem, int __val)
>  { return __sync_fetch_and_add(__mem, __val); }
> 
>  void
>  __attribute__ ((__unused__))
>  __atomic_add(volatile _Atomic_word* __mem, int __val)
>  { __sync_fetch_and_add(__mem, __val); }
> }

Show me assembly, please. 

regards,
alexander.