This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [patch] Make std::tr1::shared_ptr thread-safe.
- From: Jonathan Wakely <cow at compsoc dot man dot ac dot uk>
- To: Peter Dimov <pdimov at mmltd dot net>
- Cc: libstdc++ at gcc dot gnu dot org, Alexander Terekhov <TEREKHOV at de dot ibm dot com>
- Date: Tue, 29 Mar 2005 15:55:44 +0100
- Subject: Re: [patch] Make std::tr1::shared_ptr thread-safe.
- References: <20050329130005.GA58022@compsoc.man.ac.uk> <00b801c5346a$600bf020$6601a8c0@pdimov>
On Tue, Mar 29, 2005 at 05:19:49PM +0300, Peter Dimov wrote:
> Jonathan Wakely wrote:
> >These patches make std::tr1::shared_ptr thread-safe and change some
> >tests to check equality, not inequality, since we know what value we
> >expect and it's better to be precise about what we're checking.
>
> It is, unfortunately, still not thread safe. There are two memory
> visibility issues with the code.
Ouch. First of all, thanks for the review, Peter.
> (here I am assuming that __exchange_and_add has unspecified memory
> synchronization properties.)
I never got a clear answer on that, but I think that's the case in
general.
> I'm inclined to "ignore" this problem from shared_ptr's side and rely on
> documentation or custom deleters instead to make X responsible for its
> synchronization, because the barriers on every release() may introduce a
> significant performance hit, at least in theory. (An empty lock/unlock at
> the beginning of ~X would be enough.)
That might be consistent with libstdc++'s general thread-safety policy,
which is not to lock everything possible and to rely on the user to do
it where required.
> The second problem is that there must exist a release/acquire pair between
> the dispose() and destroy() calls, otherwise ~_Deleter will not be able to
> observe the effects of _M_del( _M_ptr ).
I see.
> Unfortunately, while libstdc++ has _GLIBCXX_READ_MEM_BARRIER and
> _GLIBCXX_WRITE_MEM_BARRIER (which purpose I don't understand that well),
> these cannot be used as an acquire/release pair, IIUC. (But I barely
> understand memory visibility.)
I come in somewhere below "barely"
> The only reliable implementation of these barriers that I see is an empty
> pthread_mutex_lock/pthread_mutex_unlock pair. This is likely to be a bit
> more expensive than necessary.
Ouch, again.
I think my patch should be applied anyway, as it's an improvement, and
these other problems can be tackled one by one. I have a lot of reading
to do so I can get up to speed on these issues!
Thanks again for the comments (I guess you're not keen to see me screw
up your shared_ptr :-)
jon
--
"Life does not cease to be funny when people die any more than it ceases
to be serious when people laugh."
- George Bernard Shaw