Discussion :

[barbug]

Slt, j'ai un thread qui va en créer plusieurs et leur donner chacun une tache. Je voudrais que ce thread sur veille ensuite tous les threads et dès qu'un a terminé, il lui envoie du travail. J'ai bien sûr pensé à une boucle qui vérifie tout le temps qu'un thread soit fini si oui, on lui envoie du boulot mais c'est assez barbare ! Existe-t-il donc une fonction à peu prés équivalente à un select pour les sockets ou fifo qui permet de bloquer jusqu'à ce qu'un ait fini ? J'ai sinon pensé à faire réceptionner les signaux de fin mais après comment faire attendre le thread sans faire d'attente active ? Une sorte de wait signal quoi !

Merci d'avance !

[yan]

Salut.
Que veut tu dire par une thread qui ne fait rien?

peut être avec ceci
http://qt.developpez.com/doc/latest/....html#finished

ou en utilisant un pool de thread et des runnable :
http://qt.developpez.com/doc/latest/...l.html#details
http://qt.developpez.com/doc/latest/qrunnable.html

Ou peut être les concurrent
http://qt.developpez.com/doc/latest/qtconcurrent.html

[barbug]

Ben en fait, je voudrais "surveiller" les threads et dès qu'un a fini que j'en soit informé. Comme la fonction select. Effectivement, comme vous m'avez proposé, je peux agir dès que je reçoit un signal d'un thread qui se termine. Mais je fais quoi comme attente ? Obligatoirement une attente active ? Ou existe-t-il un moyen "d'attendre" un signal de manière passive (en évitant une sorte de boucle infinie ! ) ?

Merci d'avance !

[yan]

Effectivement, comme vous m'avez proposé, je peux agir dès que je reçoit un signal d'un thread qui se termine. Mais je fais quoi comme attente ?

ben rien, tu as l'eventloop qui tourne, mais ne fait rien, et dés que le signal est emit, un slot est exécuté.

Si tes thread effectue des traitements très rapide, je pense qu'une solution avec un pool de thread et des runnable sera plus efficace. Ou avec les QtConcurrent. Histoire de ne pas recréé un thread à chaque fois.


[edit]
tu peut tutoyer

[IrmatDen]

Salut,

Pourquoi ne pas avoir une approche légèrement différente ?

* Le maitre (M1) possède n travailleurs
* chaque travailleur possède sa propre file de tâche(s)
* dès que le travailleur a fini sa file de tâche, il se met en sommeil (comme l'a dit mongaulois, ça passerait par une boucle d'événement locale au thread)
* Dès que le maitre reçoit une tache d'un quelconque autre maitre (M2 pour faire la distinction), il trouve le thread qui a le moins de tâches en file et lui assigne
* Si le thread n'avait pas de tâches en file ni de tâche en cours, le maitre réveille le thread par un signal (toujours comme l'a dit mongaulois )

Le "problème" de Qt Concurrent est qu'il ne supporte pas l'ajout de tâches contrairement à TBB. Tu donnes une série de tâche et il les exécute; c'est tout.

[yan]

Le "problème" de Qt Concurrent est qu'il ne supporte pas l'ajout de tâches contrairement à TBB. Tu donnes une série de tâche et il les exécute; c'est tout.

Quand j'avais regardé de plus prés, il me semblais que tout les appel concurrent on le même pool de thread et donc chaque appel était en attente jusqu'à ce qu'une thread est libre.
Donc pour moi, cela reviendrais au même.