Boost: what exactly is not threadsafe in Boost.Signals?

Question

I read at multiple places that Boost.Signals is not threadsafe but I haven't found much more details about it. This simple quote doesn't say really that much. Most applications nowadays have threads - even if they try to be single threaded, some of their libraries may use threads (for example libsdl).

I guess the implementation doesn't have problems with other threads not accessing the slot. So it is at least threadsafe in this sense.

But what exactly works and what would not work? Would it work to use it from multiple threads as long as I don't ever access it at the same time? I.e. if I build my own mutexes around the slot?

Or am I forced to use the slot only in that thread where I created it? Or where I used it for the first time?

Answer 1

I don't think it's too clear either, and one of the library reviewers said here:

I also don't liked the fact that only three times the word 'thread' was named. Boost.signals2 wants to be a 'thread safe signals' library. Therefore some more details and especially more examples concerning on that area should be given to the user.

One way of figuring it out is to go to the source and see what they're using _mutex / lock() to protect. Then just imagine what would happen if those calls weren't there. :)

From what I can gather, it's ensuring simple things like "if one thread is doing connects or disconnects, that won't cause a different thread which is iterating through the slots attached to those signals to crash". Kind of like how using a thread-safe version of the C runtime library assures that if two threads make valid calls to printf at the same time then there won't be a crash. (Not to say the output you'll get will make any sense—you're still responsible for the higher order semantics.)

It doesn't seem to be like Qt, in which the thread a certain slot's code gets run on is based on the target slot's "thread affinity" (which means emitting a signal can trigger slots on many different threads to run in parallel.) But I guess not supporting that is why the boost::signal "combiners" can do things like this.