Discussion :

[Flitz]

Salut à tous

je suis en train de programmer une application en Java et j'ai besoin des threads. J'en ai déjà eu besoin auparavant mais ici j'ai un petit problème de conception, je ne vois pas trop comment m'y prendre. Quand je parle de conception c'est quels outils de Java utiliser, c'est comment organiser mon appli. Une fois l'outil désigné il n'y a pas de problème.

Voici donc ce que j'essaie de faire. Je possède un vecteur d'objets, tous les mêmes. J'aimerais lancer un thread pour chacun de ces objets. Le thread de chaque objet doit alors réaliser certaines opérations et compléter les informations dans les champs de son objets. Soit X le nombre de thread (et donc d'objets dans le vecteur). J'aimerais qu'une fois que les X threads ont fini de bosser, càd que toutes les infos sont stockées dans le vecteur (tous les champs des objets sont remplis), qu'un autre thread complètement différent (ou même le thread qui a lancé tous les X autres) soit réveillé. Ce thread devra alors compléter une base de données avec les infos recueillies par les X autres threads.

Je viens de chercher sur le net et j'ai effectivement trouvé pas mal de chose. Cependant, il ne s'agit pas du tout d'un problème de gestion de données partagées puisque chaque thread a son propre objet. J'aimerais faire attendre le thread de la base de données tant que le vecteur n'est pas complet. Si je n'avais que deux threads j'aurais pu jouer avec synchronized ou notify mais là j'en ai tout un groupe et un différent.

Je suis tombé sur la méthode "join()" pour faire attendre la fin d'un thread mais je me vois mal faire un truc du genre

T1.join();
T2.join();
....
T100.join();

pour faire attendre mon thread BD sur tous les autres.

Comme je vous l'ai dit, ce n'est pas l'implémentation même qui pose problème mais plutôt l'outils, méthodes, ... à utiliser. Je suis aussi tombé sur des "groupes" de threads, pensez-vous que ce soit une bonne idée.

Je recherche la rapidité et l'efficacité avec consommation min de mémoire et CPU (donc boucle infinie on oublie ;-)).

Auriez-vous des conseils ou idées ?

Merci d'avance.

[afrikha]

Pourquoi ne pas rassembler tes X threads dans un ThreadGroup ?

[EDIT] je pense qu'il est là pour étre utiliser dans des cas pareils, mais je ne suis pas un spécialiste du multithread donc c'est à confirmer.
Sinon peut-etre que dans la nouvelle api java.concurrent de java1.5 il y a quelque chose qui pourrait faire l'affaire ?

[Flitz]

beh justement je me posais la question ;-).

merci de ta réponse, je vais regarder tout ça

[alexismp]

Disons plutôt java.util.concurrent: http://java.sun.com/j2se/1.5.0/docs/...e-summary.html
et les implémentations "Executor".

[afrikha]

oui merci de m'avoir corrigé.
Il y a mème une présentation de cette api sur ce site ,ici

[Flitz]

Merci de vos réponses !

Je crois avoir trouvé mon bonheur dans les loquets ;-)

merci encore

[afrikha]

un petit tag ?

[thewho]

Pourquoi ne pas rassembler tes X threads dans un ThreadGroup ?

Hum,

A thread group holds a collection of threads. The value of thread groups can be summed up by a quote from Joshua Bloch,[72] the software architect at Sun who fixed and greatly improved the Java collections library in JDK 1.2:

“Thread groups are best viewed as an unsuccessful experiment, and you may simply ignore their existence.”

If you’ve spent time and energy trying to figure out the value of thread groups (as I have), you may wonder why there was not some more official announcement from Sun on the topic, sooner than this (the same question could be asked about any number of other changes that have happened to Java over the years).

[afrikha]

je pense qu'il est là pour étre utiliser dans des cas pareils, mais je ne suis pas un spécialiste du multithread donc c'est à confirmer.

mais merci pour l'info quand mème, mais je ne sais pas quelle en est la véracité vu que je n'ai rien vu de pareil sur le site de sun !!