Boost logo

Boost :

From: Doug Gregor (dgregor_at_[hidden])
Date: 2007-01-29 14:43:17


On Jan 10, 2007, at 3:23 PM, Braddock Gaskill wrote:

> I've implemented some limited thread-safe extensions to the boost
> signals library for my own use. My signal_mt, connection_mt, and
> scoped_connection_mt classes provide some basic multi-threaded
> functionality, although I certainly don't pretend they are
> particularly mature or elegant.
>
> For the curious, my thread-safe extensions can be found at:
> http://braddock.com/~braddock/signals_mt/

Great! This is a oft-requested feature, but not one I'll be able to
address in the foreseeable future. I'm glad to see that you're
working on it!

> Included is some unit testing code which provides some usage examples
> and reasonably good code coverage (although it is not fully
> stand-alone).

Ah, good. I expect we'll need something like random_signal_system
(but multithreaded) to really bang on the implementation. That one
test caught a huge number of bugs in the handling of vertex (dis)
connections while the signal is being called.

> I was curious if experienced eyes on the list could point out any
> serious flaws or suggestions.
>
> A multi-threaded signal concept inherently needs to be treated with
> some care, since the slots need to be prepared to be called from any
> thread -- or, preferably, signaling should be restricted by design to
> one thread.
>
> A particular weakness in this implementation is that the signal
> remains (recursively) mutex locked during the iteration through
> connected slot calls.

Eric Niebler had some good ideas to eliminate the need for this lock:

        http://archives.free.net.ph/message/20040505.031148.7f072287.en.html

> I also have not added code for more than zero,
> one, or two parameter signals -- although it is trivial to do so. I
> hoped to get some feedback first (or find more bugs before I had to
> fix each one in 10 places).

Yeah, this is a pain. Signals uses the preprocessor library to
eliminate a bunch of the redundancy, but it can still get pretty ugly.

        Cheers,
        Doug


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk