Différence boost.signals / boost.signals2, safe-thread ?

Bonjour.

La dernière version de boost propose une nouvelles bibliothèque pour gérer les signaux / slots. La seul grosse différence semble être que la nouvelle est safe-thread. Je ne comprend pas trop ce qu'il faut comprendre par safe-thread ? Pour un exemple concret, imaginons que j'ai une classe qui contient un signals, et 2 threads qui utilise une référence sur une même instance de cette classe. Avec la première version de signal pour l'utilisé il fallait vérouiller un mutex à chaque fois qu'un des thread allait utilisé le signal de la classe, est ce qu'avec la version 2 on peut utilisé le signal de la classe sans vérouiller de mutex ou est ce que la signification est autre ?

Merci d'avance.

PS : signals2 est header only, alros que signal1 devait être linker, ca a un impact sur les vitesses / performances de compilation / execution ?

Salut,

Citation:

---

Envoyé par Flob90

Bonjour.

La dernière version de boost propose une nouvelles bibliothèque pour gérer les signaux / slots. La seul grosse différence semble être que la nouvelle est safe-thread. Je ne comprend pas trop ce qu'il faut comprendre par safe-thread ? Pour un exemple concret, imaginons que j'ai une classe qui contient un signals, et 2 threads qui utilise une référence sur une même instance de cette classe. Avec la première version de signal pour l'utilisé il fallait vérouiller un mutex à chaque fois qu'un des thread allait utilisé le signal de la classe, est ce qu'avec la version 2 on peut utilisé le signal de la classe sans vérouiller de mutex ou est ce que la signification est autre ?

Merci d'avance.

---

Cela signifie surtout que la gestion mutli-thread elle-même est plus naturelle et naturellement safe.

En effet, tu pouvais avoir, dans la première version, certaines surprises si tu l'utilisais en environnement multi-threadé, par exemple, si deux threads séparés tentaient d'enregistrer un slot ou un signal identique au même moment.

Signals2 permet d'assurer la sécurité à ce genre de niveau, de manière transparente pour l'utilisateur (sans nécessiter le recours à "autre chose") et de manière plus naturelle :D

Citation:

---

PS : signals2 est header only, alros que signal1 devait être linker, ca a un impact sur les vitesses / performances de compilation / execution ?

---

Beaucoup de bibliothèques de boost devaient à la base être compilées sous la forme de dll's (je pense, entre autres, à filesystem et à d'autres ;))

Depuis, il me semble, la version 1.38, l'accent a été mis sur le fait de permettre un usage "headers only" de l'ensemble des bibliothèques.

L'avantage principal que l'on en retire est, tout simplement, de ne pas rajouter une dépendance vis à vis de la dll correspondante (qui implique l'ajout d'option de configuration et de liaison et la nécessité de fournir la dll en question afin de s'assurer de sa présence sur le système d'installation) ;)

Un deuxième avantage, moins important, il faut bien l'avouer, tient dans le fait que la compilation "directe" est souvent de nature à ne laisser le code exécutable que des parties utiles et nécessaires à ton projet (du moins est-ce le cas pour toutes les bibliothèques basées sur des templates).

L'inconvénient majeur que l'on peut trouver à cet état de fait est qu'effectivement, cela peut allonger quelque peu le temps de compilation (du simple fait qu'il faut... générer le code exécutable qui tenait à l'époque dans la dll et qui n'était généré qu'une fois lors de l'installation de boost).

C'est la raison pour laquelle il reste toujours possible de créer les dll's des diffférentes bibliothèques de boost, et de les utiliser à l'instar de ce qui se faisait avant ;)

Finalement, maintenant tu as simplement le choix entre utiliser la dll (à lier correctement avec ton application) en évitant le temps de compilation du code exécutable correspondant ou éviter d'utiliser la dll (et donc de complexifier les règles de compilation de ton projet) en... perdant un peu de temps lors de la compilation (mais en n'ayant que les parties réellement utiles et nécessaires de la bibliothèque correspondante dans ton projet)

En gros, ici thread-safe veut dire :

Imagine que tu as une classe qui récupère des données sur le réseau. Disons que cette classe est instanciée dans un thread T1. Hop, elle a un message. Elle déclenche alors le signal

Code:

---

jai_recu_un_message(const std::string&)

---

Ce signal est connecté à un "slot" d'un widget de ton interface graphique qui affiche tel quel le message reçu. Disons qu'il s'appelle

Code:

---

affiche(const std::string&);

---

Evidemment, ton interface graphique est instanciée et gérée dans un thread T2 séparé de T1.

Avec boost.signals premier du nom, ce scénario n'était pas possible. Tu ne peux pas connecter un signal de quelque chose qui est dans un thread T1 avec un slot de quelque chose qui est dans un thread T2. Avec boost.signals2, c'est possible car les mécanismes de connexion et de déclenchement gèrent le fait que les différentes choses peuvent se situer dans des threads différents. C'est ça, être thread-safe.

Citation:

---

Envoyé par Alp

Avec boost.signals premier du nom, ce scénario n'était pas possible. Tu ne peux pas connecter un signal de quelque chose qui est dans un thread T1 avec un slot de quelque chose qui est dans un thread T2. Avec boost.signals2, c'est possible car les mécanismes de connexion et de déclenchement gèrent le fait que les différentes choses peuvent se situer dans des threads différents. C'est ça, être thread-safe.

---

:koi:

pour que ton slot soit exécuté dans le bon thread, il te faut un truc comme une eventloop et des relations entre un slot et un thread. Sinon je voie pas comment c'est possible. C'est ce que Qt propose.

Boost::signal2 est thread-safe dans sa manipulation (ajout/retrait de slot) mais l'appel entre le signal/slot est un appel directe. Dans ton exemple le slot de ta widget est exécuté dans la thread de l'émetteur et non celui de ta widget.

+1 avec le dernier post