[Thread] Travail en parallèle et attente

Bonjour,
Je me posais une question, et je ne sais pas vraiment comment le faire, ou plutôt comment bien le faire, je vous explique donc mon problème.

J'ai un traitement, une fois que celui ci est finit, je dois en lancer 4 en parallèle, et attendre que les 4 soient terminé pour lancer un autre traitement, dans ces traitement je suis susceptible de mettre également à jour l'interface graphique, qui est en swing.

Je me demandais donc comment faire cela proprement.

Merci d'avance pour votre aide
Nicolas,

Hello,

Pour la première attente, tu peux utilise la méthode join() de la classe Thread, qui attend que la méthode run soit terminée.

Pour l'attente des 4 threads, tu peux utilise le système de barrière.

Tu créé une barrière de X slot. (4 dans ce cas), quand tu lances tes traitements, tu met un flag a chaque slot.

Et tu met un objet en attente sur la barrière. Cet objet lancera le(s) traitements une fois que les (4) traitements seront terminés.

Ensuite tu attends que chaque thread te signale qu'il a finit, à ce signal tu change le flag.

Une fois que la barrière a reçu tout les signaux (les 4), elle s'ouvre et ton traitement continue.

Ou tu peux utiliser l'api concurrent de java 5, qui définit une classe CyclicBarrier je pense (qui est, je suppose, du même principe). Je n'ai jamais utilisé cette implémentation en revanche.
Le faire toi même peut-être interessant si la barrière attends des signaux du réseaux.

Voila, j'espère avoir pu t'aider

Pour la mise à jour de ton interface graphique, il faut bien faire attention de la faire dans l'Event Dispatch Thread (le thread dédié de Swing) via le code suivant :

Code:

---

1 2 3 4 5 6 7 8

SwingUtilities.invokeLater( new Runnable(){ public void run(){ //ici le code qui met à jour ton interface graphique } } );

---

Merci beaucoup pour votre aide, l'objet CyclicBarrier me parait très interessant, cependant, j'ai trouvé également

Code:

---

ExecutorService executor = Executors.newFixedThreadPool(liste.size());

---

Qui permet de faire à priori la même chose, il possède une méthode invokeAll(..) qui permet de lancer et attendre la fin de thread, donc c'est ce que je cherchais.

Par contre dans l'éxemple que j'ai trouvé sur ExecutorService, il passais en argument le nombre de processeur, qu'est ce que cela change, j'ai pour ma part passé le nombre de thread que j'allais lancer, est ce ainsi qu'il faut faire ?

Salut,

Citation:

---

Envoyé par Jabbal'H

Par contre dans l'éxemple que j'ai trouvé sur ExecutorService, il passais en argument le nombre de processeur, qu'est ce que cela change, j'ai pour ma part passé le nombre de thread que j'allais lancer, est ce ainsi qu'il faut faire ?

---

Le fait d'utiliser un nombre de threads correspondant au nombre de processus permet d'optimiser les traitements, et d'éviter de créer un trop grand nombre de thread. En fait si tu as plus de threads que de processus, le travail en parallèle est "simuler" en donnant la main aux différents threads les un après les autres.

Si le nombre de thread est trop important, cela peut provoquer une surcharge du système sans pour autant que cela se concrétise réellement par un gain de performance...

Prenons un exemple : tu as 100 tâches à exécuter sur une architecture avec 2 processeurs :

• Si tu utilises 2 threads les tâches vont bien se répartir sur les différents processeurs, et comme tu exécuteras tes tâches deux par deux ton temps de traitement va logiquement se diviser par deux.
• Si tu utilises 100 threads le traitements ne sera pas plus rapide car bien que tu lances 100 tâches en parallèles, il n'y en as que deux qui s'exécuteront en même temps, et le système passera de l'un à l'autre un grand nombre de fois...

Sans comptez que tu dois partager le temps processus avec les autres applications. Un très grand nombre de thread pourrait induire une forte consommation CPU inutilement et gêner les autres applications...

Si tu as un petit nombre de tâche tu peux les exécuter toutes à la fois... sinon met toi un nombre de thread limite ;)


a++

PS : Pour les traitements sur l'interface graphique, tu peux te baser sur les SwingWorker (qui peuvent être directement exécutés par les ExecutorService).

PS2 : N'oublie pas d'arrêter le pool de thread via shutdown() lorsque tu n'en as plus besoin, sinon les threads resteront endormis mais bel et bien vivant !

Merci pour cette explication, je me suis fait avoir le premier coup avec le shutdown, j'ai vite compris ;)