signal et fente vs multithreading dans la bibliothèque Boost

Question

Je suis passé par des questions similaires sur Stackoverflow mais ne peut toujours pas obtenir une bonne réponse:

1. how boost implements signals and slots
   
2. How signal and slots are implemented
   

Je suis assez perplexe sur la façon dont ce signal/slot est atteint. Q1: A partir du code suivant, sig est connecté à deux fonctions (Hello() et World()), et il semble que les fonctions sont appelées de manière sérialisée, ce qui implique également qu'une fonction (Hello ()) doivent être complétés avant d'aller dans une autre fonction (World())? => Programme à un seul fil

Q2: Y a-t-il un quelconque moyen d'activer le signal/slot multithread? (=> World() démarrera instantanément, pas besoin d'attendre Hello() pour terminer.) Ou si c'est non recommandé, cela vous dérangerait-il de me dire pourquoi?

Sample codes on Boost website:

struct Hello 
{ 
    void operator()() const { std::cout << "Hello";} 
}; 
struct World 
{ 
    void operator()() const { std::cout << ", World!" << std::endl;} 
}; 

boost::signal<void()> sig; 
sig.connect(Hello()); 
sig.connect(World()); 
sig(); 

Sortie: Bonjour, monde!

Answer 1

Q1:
Les appels sont sérialisés. Ce que les signaux font en interne est, grandement simplifié:

foreach connection: 
    call handler 

Par conséquent, vous ne voulez pas bloquer dans les gestionnaires pour longtemps. Si vous avez besoin de beaucoup de travail, vous pouvez l'invoquer à partir de là, par exemple en créant un thread pour cela.

Q2:
les signaux d'amplification 1 ne sont même pas thread-safe; signaux 2 est, mais fait toujours des appels sérialisés. Comme les signaux sont principalement utilisés pour la gestion des événements, il est courant de ne pas faire beaucoup de travail dans les gestionnaires.
Ainsi, il n'y a pas de réel avantage à les appeler «en parallèle», les avantages ne justifieraient en général pas la surcharge des invocations de threads nécessaires.

Answer 2

Q1: vous avez raison. Correction de my answer à the question vous avez référencé pour refléter cela. Q2: il semble que vous êtes confus par ce qui doit être enfilé. Dans le processus d'émission/capture, contient le code. Donc, si vous voulez exécuter le code simultanément, vous devez placer les emplacements dans différentes discussions.

Un tel comportement est supporté par Qt (ne sait pas sur boost, en fait), et il y a a chapter dans le manuel qt qui explique, que vous avez probablement besoin de "traitement en file d'attente" pour un tel comportement. Mais alors vous devrez avoir la notion de "boucle d'événement" dans le thread qui exécute le code de slot (parce que vous ne pouvez pas dire au thread de travail "hey, arrêtez de faire vos trucs, faites-le à la place!").

Si vous ne voulez pas attendre, vous devrez générer des threads directement dans les codes d'emplacement. Et vous ne devriez pas oublier d'utiliser une sorte de fonction "wait" dans le code auquel les deux slots ont accès. En passant, boost et Qt ont de beaux wrappers autour des bibliothèques de threads du système pour le faire facilement.