Re: Tweaking atomics and memory barriers in shared_ptr

[Paolo Carlini <pcarlini at suse dot de>]

Hi Jonathan,
> The performance issues are:
> 1) The memory barriers in _Sp_counted_base are suboptimal in the
> common case. The __sync builtins are already fully-fenced, so the
> explicit memory barriers are redundant when the lock-policy is
> _S_atomic (which happens when we know we have a builtin CAS).
> This is mentioned in http://gcc.gnu.org/ml/libstdc++/2005-11/msg00136.html
> My suggestion is to make the memory barriers depend on the lock policy
> rather than the __GTHREADS macro. The memory barriers are only needed
> for the _S_mutex policy, because that policy is used when we don't
> have __sync_* builtins, which means the atomic ops don't have any
> memory synchronisation guarantees.
>   
Ok, let's do this.
> 2) When lock-policy is _S_single the atomic *_dispatch functions in
> ext/atomicity.h are used. For single-threaded code this doesn't
> matter, but if __shared_ptr<T, _S_single> is used by multithreaded
> programs then the lock-policy is not honoured, since fully-fenced
> atomic ops will be used.
>   
I'm much less enthusiastic about this part. Indeed, I noticed the issue
some time ago, when I cleaned-up this stuff, but didn't consider the
_S_single case to be worth the additional specializations. All in all,
I'm in favor of committing immediately the hunks above (+ the volatile
bit), then we'll see...

Thanks,
Paolo.