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?

Tallulah

It's been a while...did my answer to this make sense? Basically the signals library itself won't crash regardless of the calls you make from any threads so long as they are "valid"...but you're responsible for the semantics in your own code. – Polyphony

Yea it makes sense but it doesn't really answer all my questions. :) Basically you said "look it up in the source". I will do that at some later point and then post all the exact answers to my questions here. – Tallulah

You did ask "what exactly works and what would not work?" I felt that was more essential than dissecting your narrower specific questions. (Those answers are "Yes: if you guard with a mutex that's fine, but possibly unnecessary if the semantics of your slots are such that more than one thread can be running them at a time; it's like calling any other function from multiple threads" and "No: you are not restricted to using slots only in the threads where they are created.") – Polyphony

More to the point, the real question you were asking here is "what does it mean when library authors say their library is 'thread-safe'" Knowing the answer to that is more generally applicable than to just Boost.Signals, and expecting the audience to know the general concept is probably why they didn't feel it necessary to explain in detail in the documentation. – Polyphony

Also: I did NOT just flippantly say "read the source". I linked to a precise source file and the functions to look for. Because in the absence of documentation, that really is the only way to know the answer to questions like "what happens if I disconnect a signal from a slot while that signal is being emitted and the slots are called on another thread...will it finish calling the slots or might it remove a slot in the middle". There is no other way to answer "what exactly works and what would not work". – Polyphony

Hm you linked to a signals2 source. Anyway, my question really was about what is not threadsafe in signals. I haven't looked at the source of signals1 yet (otherwise my question would be obsolete anyway because I would have seen it then). And depending on the implementation, it's possible that even a mutex or whatever other semantic bounds would not help at all - that's why I asked (and because the answer could be interesting for others). I guess I will take a look at the code later on and see if it can be used as one would expect. – Tallulah

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.

Polyphony

Answer 2

One problem I see is that one thread can connect or disconnect while another thread is signalling.

You can easily wrap your signal and connect calls with mutexes. However, it is non-trivial to wrap the connections. (connect returns connections which you can use to disconnect).

Feudatory