From: Douglas Gregor (gregod_at_[hidden])
Date: 2002-01-04 11:18:26
On Thursday 03 January 2002 06:31 pm, you wrote:
> I cannot see how to _easily_ avoid this problem if one solely relies
> on boost::trackable for connection management.
I doubt that it is even possible to use the Signals library safely in a
multithreaded context. Unfortunately, it cannot by itself be made thread-safe
because it is a high-level library that depends on several lower-level Boost
libraries, none of which - to my knowledge - is thread-safe. As an example,
it isn't even safe to pass around boost::connection objects in a
multithreaded environment, because boost::shared_ptr is not thread-safe, so
the reference count could end up with the wrong value: if it is too high,
there will be a resource leak; if it is too low, there may be an outstanding
pointer to deallocated memory.
I'll look into thread safety for the Signals library from the implementation
side, but we should also discuss the user interface to specifying locking
models/policies for classes that are meant to be thread-safe. The interface
should be common across all Boost libraries that require thread safety.
> IMPORTANT: This is not meant as a critisism to the signals library or
> its designer. I (with my limited experience in multithreading) simply
> cannot figure out how to use the library safely in an MT environment.
No need to shy away from criticism. Boost is built on constructive criticism,
and without it we couldn't hope to achieve high-quality libraries.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk