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

[Alexander Terekhov <TEREKHOV at de dot ibm dot com>]

Your original patch doesn't seem to look right.

Correct logic is this: (illustration)

void add_ref_lock() {
  mutex::guard guard(lock_);
  if (use_count_.increment() == 1) { // naked atomic
    use_count_.store(0, msync::naked_noncompeting);
    throw_bad_weak_ptr();
  }
}

regards,
alexander.

Jonathan Wakely <cow@compsoc.man.ac.uk> on 03/31/2005 02:46:52 PM

To:    Paolo Carlini <pcarlini@suse.de>
cc:    Peter Dimov <pdimov@mmltd.net>, Gabriel Dos Reis
       <gdr@integrable-solutions.net>, libstdc++@gcc.gnu.org, Alexander
       Terekhov/Germany/IBM@IBMDE
Subject:    Re: [patch] Make std::tr1::shared_ptr thread-safe.


On Thu, Mar 31, 2005 at 01:03:32AM +0200, Paolo Carlini wrote:

> Peter Dimov wrote:
>
> > If that's going to be of any help, I'm planning to use Whitehead/(1)
> > in Boost on libstdc++ pre-4, and whatever you decide to use for 4 and
up.
> >
> > Thank you for reading this far. ;-)

Thank *you*, and Alexander as well.

> Thank you for your patience and willingness to explain. I was completely
> missing that there are two different issues, my bad, and only *one* can
> be dealt with via compare_and_swap, the other needs anyway plain locks.
>
> All in all, given the very delicate points at issue I don't feel like
> bringing in, so close to the release of 4.0.0, the compare_and_swap code
> and the additional complexity and configury problems (+ testing that
> everything behaves as expected on all the targets!!). Do you, Gaby?
> Please, let's try to provide a decent implementation, let's ask Jonathan
> to prepare (1) for 4.0.0, then we can discuss further improvements in a
> second moment, when this code will settle a bit.

Soooooooo, for now, I will just commit my original patch posted here:
http://gcc.gnu.org/ml/libstdc++/2005-03/msg00354.html
(after waiting a while for any more feedback)

And then address the visibility problems by adding empty critical sections
(option (1) referred to above)

And then we can discuss future improvements such as using CAS instead of
a mutex, providing synch. guarantees for the atomics, or introducing
memory barriers to libstdc++.  None of those improvements can be made
without changing other parts of libstdc++.

Please bear in mind that currently std::tr1::shared_ptr can't be used in
multithreaded code even on a uniprocessor machine where there are no
memory visibility issues!  Let's make it work first, then make it work
fast.

jon