![]() |
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, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk