Continuing my foray into the TR1: tr1::shared_ptr<>

[Emmanuel Deloget]

Hello y'all,

I'm currently writing a serie of blog tickets about the TR1, both from
a definition point of view and from an implementation point of view.
The next iteration in the series deals with the smart pointer sub-
library in the TR1 (weak_ptr, shared_ptr, enable_shared_from_this),
and guess what, I have a few question about the implementation of all
this.

Before I ask my question, I'd like to say that I studied all the
shared_ptr implementation I was able to study (namely,
boost::shared_ptr by Peter Dimov and the tr1 implementation of g++,
which is based on boost's implementation). Unfortunately, I still
don't understand something.

The TR1 says about the weak_ptr::expire() method:

bool expired() const;
Returns: use_count() == 0.
Throws: nothing.
[Note: expired() may be faster than use_count(). -end note]

The problems is about how it detects use_count() = 0. Let's examine
this code:

shared_ptr<A> sp(new A);
weak_ptr<A> wp(sp);
sp.reset();

This will transform sp into an empty shared_ptr. Typical
implementation will implement reset as:

void reset()
{
shared_ptr<T>().swap(*this);
}

This will destroy the pointer associated to sp (because the temp
object will go out of scope), and this will also destroy the internal
reference counter, as it is no more needed (shared_count = 0).

Question: if this internal reference counter is destroyed, how can
use_count() (and, of course) expired() be implemented so that they
don't crash?

Thanks for your patience

 

[Chris Thomasson]

Hello y'all,

I'm currently writing a serie of blog tickets about the TR1, both from
a definition point of view and from an implementation point of view.

Here is a fairly efficient way to implement shared_ptr:

http://appcore.home.comcast.net/vzoom/refcount/
(I expose a different interface than shared_ptr, however, it would be
trivial to make my algorithm expose it as well.)

Also, when you use something like the algorithm I created you get the added
benefit of strong thread safety. Currently, shared_ptr cannot handle strong
competing access from multiple threads... In other words, the following
scenario is a no go with current shared_ptr algorithm, and perfectly legal
with my prototype code:

// pseudo-code

static shared_ptr<foo> g_foo = new foo;

reader_threads(...) {
for(; {
{
shared_ptr<foo> l_foo = g_foo;
if (l_foo) {
l_foo->do_something();
}
}
// do something else
// ect, ect...
}
}

writer_thread(...) {
for(; {
{
shared_ptr<foo> l_foo = g_foo.xchg(new foo);
if (l_foo) {
l_foo->do_something();
}
}

// do something else
// ect, ect...
}
}




Does anybody think that shared_ptr should be able to handle a scenario like
the above? If you think so, my prototype implementation should help inspire
some other possible designs...

 

[Emmanuel Deloget]

Does anybody think that shared_ptr should be able to handle a scenario like
the above? If you think so, my prototype implementation should help inspire
some other possible designs...

This is the basic difference between the C++ standard and the real
world: as of today, the standard has no idea of what a thread is (and
as a consequence, it doesn't need to be thread-safe, although some
implementations are). It seems that the the next iteration of the C++
standard is going to introduce a thread library, so such scenario is
likely to happen.

I'm going to check your implementation soon - thanks

-- Emmanuel Deloget

 

[Chris Thomasson]

This is the basic difference between the C++ standard and the real
world: as of today, the standard has no idea of what a thread is (and
as a consequence, it doesn't need to be thread-safe, although some
implementations are).

:^)

This is why I had to implement about 99.99% of my reference counting
algorithm with pure* 32-bit x86 assembly language:

http://appcore.home.comcast.net/vzdoc/atomic/static-init/
(more on this in section 2...)

Whoa! That's some pretty tricky stuff huh? ;^)

It seems that the the next iteration of the C++
standard is going to introduce a thread library, so such scenario is
likely to happen.

Indeed! FWIW, and IMHO, I sure do think that Standard C++ would do well by
providing an atomically thread-safe smart-pointer with the ability to handle
any "strong competing accesses" a end-user application can throw at it. This
new shared_ptr would end up being more useful and flexible. For instance,
you could use it for a whole new class of multi-threaded reader-writer
patterns which were previously impossible to implement using only
shared_ptr.

Darn... I hope I don't ending up sounding like a salesman or something!

lol. :^)

I'm going to check your implementation soon - thanks

If you are having any trouble understanding the assembly language, let me
know and I will post my entire algorithm in the form of some fairly simple
pseudo-code. Well, here it is anyway since a lot of people get headaches
after reading basically any amount of assembly! ;^)


http://article.gmane.org/gmane.comp.lib.boost.devel/149803
(pseudo-code with a fairly detailed explanation...)


http://search.gmane.org/?query=&aut...ERS=Gcomp.lib.boost.user-Achris+thomasson---A
(contains a rather robust discussion about the algorithm over on the boost
developer list...)


Enjoy! :^)


* - I did not use any inline assembly. IMHO, it's safer to use a "real"
assembler to do this sort of stuff... For instance, instead of using inline
asm in GCC, you should probably be using GAS instead...