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