From: Greg Colvin (gcolvin_at_[hidden])
Date: 1999-07-24 10:50:46
> I have a related question: How would you use all these smart pointers in
> multithreaded environments? (It's not a provocation but a very practical
> issue - some kind of automatic garbage collection is usually essential in
> multi-threaded programs e.g. dealing with GUIs.)
Right now, you don't. We need a thread-safe version of shared_ptr.
> Here is the situation I am thinking about: you have a refcounted object
> rco which is referenced in object a1. Imagine further that thread 1 is
> calling into one of rco's method through the reference in object a1 which
> starts some long lasting computation. Now thread 2 somehow arrives at a1
> and decides to discard the reference to object rco which happens to be the
> very last reference to object rco. Therefore the reference counting
> mechanism decides to delete object rco - an object which is "computing"
> something. Afterwards devil things may happen. E.g. the reference
> to the virtual table that lived in object rco may be reused for some other
> purpose and if thread 1 tries to call a virtual function of object rco
> then the system will probably crash.
> This is not akin to C++, of course you can simulate objects and virtual
> method tables in C.
> The only way out that I can imagine is to protect every call into the
> object and also every parameter passing (i.e. adjust the reference count
> every time to call into the object or when you pass the object as a
> parameter). But this would require quite a bit of additional work..
You can play some non-portable tricks to reduce the overhead -- some
> I think that the conservative garbage collector of Boehm would also be
> fooled by the above code - after discarding the reference to object
> rco in object a1 there are no real references to object rco anywhere in
> the program so the Boehm collector would collect it. I am not sure about
> Great Circle, I am not familiar with that collector.
These collectors are both thread-safe. Check out:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk