Discussion :

[Invité]

Bonjour,

Je développe actuellement une application et je bloque sur l'architecture à adopter pour la faire tourner en multi-thread.

Mon besoin consiste à faire tourner un premier thread servant à communiquer avec un appareil de mesure, puis à envoyer les résultats à second thread chargé de traiter ces données pendant que le premier thread exécute le cycle de mesures suivant. Ces deux thread son membre d'une classe Manager chargée d'assurer leur création et la communication avec l'IHM. Cette classe doit également récupérer les données traitées et le rediriger vers les modules idoines (IHM pour affichage et/ou modèle pour persistence).

J'ai lu et relu FAQ, Doc et tutos sans parvenir à faire émerger une solution pertinente.

La solution consistant à utiliser un moveToThread() vers un objet QThread ne me semble pas plus pertinente que celle consistant à hériter directement QThread et dans les deux, j'aurais de sérieuses difficultés à faire communiquer ou fonctionner les différents parties de mon application comme je l'entend.

Mes yeux me piquent à force de lire et relire des articles et forums qui commencent à se répéter, je m'en remet donc à vous.

[yan]

Salut,

La solution consistant à utiliser un moveToThread() vers un objet QThread ne me semble pas plus pertinente que celle consistant à hériter directement QThread et dans les deux, j'aurais de sérieuses difficultés à faire communiquer ou fonctionner les différents parties de mon application comme je l'entend

La différence se situe sur l’exécution des slots de ton objet. Pour qu'un slot s'éxécute dans un thread il faut que le thread lance l'eventlloop et un QThread ne doit pas être associé au thread qu'il interface. C'est pour cela que faire un QObject et l'associé à un QThread est intéressant.

Pour la communication et le fonctionnement de tes différentes parties, faudrait que tu explique plus.

[Invité]

Mon thread numéro 1 doit utiliser une procédure précise qui se répète indéfiniment, ma première idée était donc un while dans le run() du thread. Le problème ici est qu'il pas d'eventloop, or, pour envoyer les résultats au thread n°2 à chaque itération, il faut des signaux et slots (d'après mes lectures, c'est le seul moyen de faire communiquer des threads entre eux). Donc ce n'est pas viable.

La seconde solution, un QObject envoyé à un thread, règle ce problème;

Mais cela me pause un tout autre problème.
- Premièrement, cette procédure nécessite de mettre le thread en pause à certains endroits, ce qui n'est plus possible puisque l'objet, dans ce cas, n'hérite pas de QThread et la fonction sleep est protected (bien que la doc la prétende publique).

De plus, je suis peu familier du multi-threading, et je suis encore en train de réfléchir, laborieusement, à la façon de faire se répéter inlassablement la procédure sus-mentionnée. Manifestement, je ne sais pas raisonner en multi-threading, et je me demande où je dois placer ce while dans la deuxième solution.

[yan]

Mon thread numéro 1 doit utiliser une procédure précise qui se répète indéfiniment, ma première idée était donc un while dans le run() du thread. Le problème ici est qu'il pas d'eventloop, or, pour envoyer les résultats au thread n°2 à chaque itération, il faut des signaux et slots (d'après mes lectures, c'est le seul moyen de faire communiquer des threads entre eux). Donc ce n'est pas viable.

Il te faut l'eventloop uniquement pour l'execution du slot pas pour l'envoie du signal. DOnc ton thread 1 n'en as pas besoin s'il ne fait qu’émettre des signaux.

La seconde solution, un QObject envoyé à un thread, règle ce problème;

...

J'ai pas trop compris ton explication....

[Invité]

En somme :

Thread n°1 :

Ce thread exécute une procédure qui prend du temps. Pour le faire sans bloquer l'IHM, il me faut l'exécuter dans un thread autre que le thread principal. Et pour recevoir les ordres venant du thread principal (commence, arrête, etc), j'ai besoin des slots, il me faut donc un eventloop.

Donc, la solution que j'ai adopté consiste à créer simplement cet objet en faisant de ses fonctions des slots. L'un des membres de cet objet est un QThread. J'utilise sur mon objet la fonction moveToThread afin de faire exécuter ses slots dans le contexte du QThread créé (différent du thread principal).

Sauf qu'au cours de cette procédure, j'ai besoin de faire des pause, et je ne peux pas utiliser la fonction sleep de QThread depuis mon objet car elle est protected et ne peut être utilisée que par un objet héritant de QThread. Sur ce point j'ai opté pour la seule solution à laquelle j'ai pensé : j'ai utilisé, en lieu et place du QThread, un objet dérivant QThread et dont la seule différence avec son parent consiste à rendre publique la fonction sleep;

Thread n°2 :

Ce Thread est en charge de traiter les données récoltées par le thread n°1 pendant que ce dernier effectue le cycle suivant de sa procédure. Ce traitement peut prendre plusieurs secondes selon l'ampleur des données reçues, et ne doit pas bloquer ni l'IHM ni le thread n°1. Il me faut donc un troisième contexte de thread.

J'ai opté ici pour la même architecture que le Thread n°1. Reste à les synchroniser.

Voilà, j'espère que c'est plus clair. J'ai la tête là-dedans depuis des semaines et j'ai donc un peu de mal à m'expliquer clairement pour qui ne connait rien du projet.

Cette architecture vous semble-t-elle correcte ? Réaliste ? Complètement aberrante ?

[yan]

Pourquoi le sleep?

[Invité]

Parce que je n'ai pas trouvé d'autre moyen de faire faire une pause à ma procédure (une boucle while utiliserait 100% du processeur inutilement).

[yan]

Ok.
Une proposition.
Tu créé un QObject avec des signaux et des slots.

Au lieu de faire un while, tu va utiliser un QTimer. Par exemple la méthode static :
http://qt-project.org/doc/qt-4.8/qtimer.html#singleShot

Le contenue de ta bloucle est un slot connecté au timer

Tu associe ce QObject a un QThread pour que ses slot s’exécute dans le thread.

J'ai commencé (mais pas fini...) un tuto ici : http://yan-verdavaine.developpez.com...er_l_eventloop

Ne fait pas attention au fautes...

[Invité]

J'ai fini par trouver une solution qui semble fonctionner.

Je ne comprends pas bien l'utilisation d'un QTimer, dans la mesure où dans mon cas, ce n'est pas le temps qui entre en compte, les thread doivent se synchroniser entre eux sans horloge absolue.

Mais ta réponse m'a quand même permit de trouver une solution : j'utilise des signaux et slots pour communiquer les débuts et fin de procédure.

Mon manager central lance les deux procédure puis ce place en état d'attente. Chacune de ces procédures envoie un signal au manager lorsqu'elle a terminé et le manager ne relance les procédure que lorsque qu'il a reçu les deux signaux.

L'idée est simple, mais l'implémentation semble lourde au premier abord (peut-être à cause du pattern Etat donné au manager). Cependant, je pense qu'avec la croissance de l'application, ce sera sur la durée la méthode la plus économique.

Merci beaucoup pour ton aide.

[yan]

La QTimer tu le mets à zero et il execute au plus vite ta fonction.
Le but est uniquement de déporté ta boucle dans l'eventloop du thread.

Tu peux aussi utiliser startTimer(0) et en reimplementant QObject::timerEvent(QTimerEvent*).