Pour la gestion des threads je n'ai qu'une bible :
Java Threads chez O'REILLY (il existe en fran�ais ou en anglais).
Il a toujours r�pondu � toutes mes questions m�me les plus tordues.
p�36 : Comment effectuer join() avec plusieurs threads
p�37 : for(int i=0; i<NOMBRE_DE_THREAD;i++) {
thread[i].join();
}
--------------------------------------------------------------------
Erik Mazoyer, Chef de projet
HyperOffice
6, rue Jacques Daguerre - 92565 Rueil-Malmaison Cedex
T�l. 01 41 96 96 76
Fax 01 41 96 96 77
M�l [EMAIL PROTECTED]
Nouveau cycle de s�minaires "les mardis d'HyperOffice"
Inscriptions et renseignements :
http://www.hyperoffice.fr/formation/catalogue/index.asp
-----Message d'origine-----
De : marc godin [mailto:[EMAIL PROTECTED]
Envoy� : vendredi 28 mars 2003 16:54
� : [EMAIL PROTECTED]
Objet : Re: threads
MARQUES David Ext OCISI wrote:
>la solution de Zeljko me semble bonne pour mon cas.
>par contre, une derni�re pr�cision, si je fais un truc style (�a serait plus simple
>pour moi) :
>myThreadClass1.join();
>myThreadClass2.join();
>si myThreadClass2 se termine avant le myThreadClass1, mon appli est elle bloqu�e ou
>peut importe si le join est fait apr�s que le thread ne meure ?
>merci � tous et fin pour aujourd'hui !
>
>
>
le join s'applique sur le thread courant cela ne bloque que le thread
courant c'est a dire celui de ton aplication
par les autres therad que tu as lancer
>-----Message d'origine-----
>De : Zeljko VELAJA [mailto:[EMAIL PROTECTED]
>Envoy� : vendredi 28 mars 2003 16:19
>� : [EMAIL PROTECTED]
>Objet : RE: threads
>
>
>Plus compliqu�, effectivement, mais pas impossible. Voici une fa�on de faire
>:
>
>a) cr�er une classe de gestion de tes thread (ThreadManager). Elle aussi est
>un thread.
>b) dans ThreadManager g�rer un compteur d'instances de MyThreadClass
>c) lorsque qu'un MyThreadClass commence sa m�thode run il incr�mente le
>compteur de ThreadManager
>d) lorqu'il sort de sa m�thode run, il d�cr�mente le compteur.
>e) lorsque le compteur de ThreadManager est � z�ro, poursuivre ton
>application.
>
>En fait, pourquoi ThreadManager est elle-m�me un Thread ? Parce qu'elle doit
>tester en boucle la valeur de son compteur !
>
>-----Message d'origine-----
>De : MARQUES David Ext OCISI [mailto:[EMAIL PROTECTED]
>Envoy� : vendredi 28 mars 2003 16:09
>� : [EMAIL PROTECTED]
>Objet : RE: threads
>
>
>ok pour �a, mais le second truc, c'est que je dois attendre la fin de tous
>mes threads avant d'ex�cuter la suite de mon appli.
>
>
>-----Message d'origine-----
>De : Zeljko VELAJA [mailto:[EMAIL PROTECTED]
>Envoy� : vendredi 28 mars 2003 15:44
>� : [EMAIL PROTECTED]
>Objet : RE: threads
>
>
>Pourquoi ne pas simplement appeler ta m�thode de terminaison � la fin de la
>m�thode run() de ton thread ?
>
>-----Message d'origine-----
>De : MARQUES David Ext OCISI [mailto:[EMAIL PROTECTED]
>Envoy� : vendredi 28 mars 2003 15:31
>� : [EMAIL PROTECTED]
>Objet : threads
>
>
>bonjour � tous et toutes,
>j'ai une question sur les threads :
>dans mon appli, je lance en rafale une s�rie de threads (classe
>MyThreadClass).
>ensuite je voudrais me mettre en attente et ex�cuter une m�me proc�dure
>concernant chaque thread d�s que chacun de mes threads se termine.
>je pr�cise que le nombre de threads lanc� est dynamique.
>c � dire que je voudrais un truc du style :
>while (tant que toutes mes instances de MyThreadClass ne sont pas termin�es)
>{
> attendre qu'un MyThreadClass se termine;
> quand un de mes MyThreadClass est termin�, �xecuter
>MyMrthod(myThreadClass);
>}
>voila l'id�e !
>merci.
>
>
>
>
>
