Boost: cosa non è protetto da thread in Boost.Signals?

Question

Ho letto in più punti che Boost.Signals non è thread-safe ma non ho trovato molti più dettagli a riguardo. Questa semplice citazione non dice molto. La maggior parte delle applicazioni al giorno d'oggi ha dei thread - anche se provano a essere a thread singolo, alcune delle loro librerie possono usare i thread (per esempio libsdl).

Suppongo che l'implementazione non abbia problemi con altri thread che non accedono allo slot. Quindi è almeno a prova di sicurezza in questo senso.

Ma cosa funziona esattamente e cosa non funzionerebbe? Funzionerebbe per usarlo da più thread purché non lo acceda mai nello stesso momento? Cioè se costruisco i miei mutex attorno allo slot?

Oppure sono obbligato a utilizzare lo slot solo in quel thread in cui l'ho creato? O dove l'ho usato per la prima volta?

Answer 1

Non credo che sia troppo chiara sia, e uno dei recensori della biblioteca said here:

anche io non è piaciuto il fatto che solo tre volte la parola 'filo' stato nominato. Boost.signals2 vuole essere una libreria 'segnali di sicurezza thread'. Pertanto alcuni ulteriori dettagli di e in particolare più esempi relativi a quell'area dovrebbero essere dati a l'utente.

Un modo per capire è go to the source e vedere cosa stanno usando _mutex/lock() per proteggere. Quindi immagina cosa succederebbe se quelle chiamate non fossero lì. :)

Da quello che posso raccogliere, è garantire cose semplici come "se un thread sta facendo si connette o disconnette, che non causerà un thread diverso che sta iterando attraverso gli slot collegati a quei segnali di crash". Un po 'come l'utilizzo di una versione thread-safe della libreria di runtime C assicura che se due thread fanno chiamate valide allo printf allo stesso tempo, non si verificherà un arresto anomalo. (per non dire l'uscita si otterrà sarà alcun senso — sei ancora responsabile per la semantica di ordine superiore.)

non sembra essere come Qt, in cui il filo di una certa fessura di il codice che viene eseguito è basato sull'affinità del thread dello slot di destinazione (il che significa che l'emissione di un segnale può attivare slot su molti thread diversi da eseguire in parallelo.) Ma suppongo che il supporto non sia il motivo per cui il boost :: signal "combinatori" può do things like this.

Answer 2

Un problema che vedo è che un thread può connettersi o disconnettersi mentre un altro thread sta segnalando.

È possibile avvolgere facilmente il segnale e connettere le chiamate con mutex. Tuttavia, non è banale racchiudere le connessioni. (collega le connessioni di restituzione che puoi usare per disconnettere).