This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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?

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); }
}

You can find all of them under config/cpu/*/atomicity.h. In any case,
now that we know the basic technical terms of the issue we can also
venture ;) to do the same ourselves.

Thanks again,
Paolo.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]