Boost: quoi exactement n'est pas threadsafe dans Boost.Signals?

Question

J'ai lu à plusieurs endroits que Boost.Signals n'est pas threadsafe mais je n'ai pas trouvé beaucoup plus de détails à ce sujet. Cette simple citation ne dit pas vraiment ça. La plupart des applications ont de nos jours des threads - même si elles essayent d'être à thread unique, certaines de leurs bibliothèques peuvent utiliser des threads (par exemple libsdl).

Je suppose que l'implémentation n'a pas de problèmes avec les autres threads qui n'accèdent pas au slot. Donc, il est au moins threadsafe dans ce sens.

Mais qu'est-ce qui fonctionne exactement et qu'est-ce qui ne fonctionnerait pas? Serait-il utile de l'utiliser à partir de plusieurs threads tant que je n'y accède jamais en même temps? C'est à dire. si je construis mes propres mutex autour de la fente? Ou est-ce que je suis obligé d'utiliser l'emplacement seulement dans ce fil où je l'ai créé? Ou où je l'ai utilisé pour la première fois?

Answer 1

Je ne pense pas que ce soit trop clair non plus, et l'un des examinateurs de la bibliothèque said here:

Je ne ai pas aimé aussi le fait que seulement trois fois le mot « fil » a été nommé. Boost.signals2 veut être une bibliothèque de 'thread safe signals'. Par conséquent, plus de détails et surtout plus d'exemples concernant sur cette zone devrait être donné à l'utilisateur.

Une façon de le comprendre est de go to the source et de voir ce qu'ils utilisent _mutex/lock() pour protéger. Alors imaginez ce qui se passerait si ces appels n'étaient pas là. D'après ce que je peux comprendre, cela garantit des choses simples comme «si un thread se connecte ou se déconnecte, cela ne provoquera pas un thread différent qui itère à travers les slots attachés à ces signaux pour se bloquer». Un peu comme comment l'utilisation d'une version thread-safe de la bibliothèque d'exécution C assure que si deux threads font des appels valides à printf en même temps, il n'y aura pas de plantage. (Pour ne pas dire la sortie, vous obtiendrez de sens — vous êtes toujours responsable de la sémantique d'ordre supérieur.)

Il ne semble pas être comme Qt, dans lequel le fil d'une certaine fente de Le code s'exécute est basé sur l'affinité de thread du slot cible (ce qui signifie que l'émission d'un signal peut déclencher des slots sur de nombreux threads différents en parallèle.) Mais je ne pense pas que c'est la raison pour laquelle boost :: signal do things like this.

Answer 2

Un problème que je vois est qu'un thread peut se connecter ou se déconnecter tandis qu'un autre thread est la signalisation.

Vous pouvez facilement enrouler votre signal et connecter des appels avec des mutex. Cependant, il est non trivial d'envelopper les connexions. (connect renvoie les connexions que vous pouvez utiliser pour vous déconnecter).