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

[Alexander Terekhov]

On Apr 1, 2005 5:19 PM, Paolo Carlini <pcarlini@suse.de> wrote:
[...]
> >>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.
> >
> I can dig out for you something but this case, actually, is trivial,
> right? You mentioned already that Intel's sync_fetch_and_add is ok and
> here (for ia64), we are using exactly that.

I know how Intel conforming  __sync_fetch_and_add supposed to work.

I want to see GCC's implementation on IA64 instructions level 
(effects on compiler reordering aside for a moment).

> 
> As far as the other archs are concerned, are you familiar with GCC
> inline assembly? (otherwise we can take care of that separately) I can
> show you, for instance, I don't know, what we have for i486 and later:
> 
>  _Atomic_word
>  __attribute__ ((__unused__))
>  __exchange_and_add(volatile _Atomic_word* __mem, int __val)
>  {
>    register _Atomic_word __result;
>    __asm__ __volatile__ ("lock; xadd{l} {%0,%1|%1,%0}"
>              : "=r" (__result), "=m" (*__mem)
>              : "0" (__val), "m" (*__mem));
>    return __result;
>  }

"lock; xadd" is fully fenced. But is this really correct clobber? I don't see 
"memory" in it. Oder?

[...]
> or powerpc:

Well, see

http://sourceware.org/cgi-bin/cvsweb.cgi/libc/sysdeps/powerpc/bits/atomic.h?cvsroot=glibc

I really doubt that "_STWCX" injects two syncs (around store) or something 
that provides it fully-fenced (rel+acq) effect with respect to entire operation.

regards,
alexander.