Re: creating a vector of a vector of Gtk::ToggleButton

[Chris Vine <chris cvine freeserve co uk>]

On Saturday 30 October 2004 20:14, Carl Nygard wrote:

> Alexandrescu has some nifty idioms to deal with this type of thing.  I'd
> actually be interested in trying it out, although I've read somewhere
> that making smartptr's threadsafe is difficult/impossible (I think it
> had to do with non-invasive types).

Trying to design a non-intrusive shared pointer which locks the referenced 
object itself is (I think) next to impossible.

But locking the reference count is trivial and results in having a shared 
pointer which is as thread safe as a plain pointer, and is definitely 
worthwhile.  This means that you can have shared pointers in separate threads 
safely referencing the same object (in other words, you can have different 
STL containers in different threads safely containing shared pointers 
referencing the same object).  However, the referenced object itself is 
unprotected, so that if it is not a built in type for which POSIX offers 
guarantees, you cannot even safely _dereference_ and read the same object 
concurrently.  For example, the libstdc++ implementation of std::string does 
not allow you to read the same string concurrently in different threads, 
without external locking.

But the same is true of objects accessed in separate threads without using 
shared pointers.

There are various techniques to lock the referenced object outside the shared 
pointer.  One technique I use is to have a "tunnelling" mutex pair (a 
std::pair which contains a mutex lock and a shared pointer to the object 
locked).

Chris.