. .
Version imprimable
. .
Bonjour,
Le manager. Ta première solution utilise en fait deux types de locks : sur le manager et sur chaque thread. C'est redondant. Ce qui a besoin d'être en exclusion mutuelle, c'est la méthode incrDoneThreads() du manager. Il y a pas besoin d'un autre.
A noter que si le but est juste d'attendre que tous les threads aient fini leur méthode run(), il suffit d'utiliser join(). C'est plus simple.
D'accord, merci pour ta réponse.
Mais il me semble que je ne peux justement pas faire de join() puisqu'une fois que les threads ont terminé leur travail, ils doivent recommencer une boucle (une itération).
Donc si j'attends qu'ils aient fini avec un join(), je ne pourrais pas les relancer, si ? (A savoir que le but est l'optimisation temporelle donc attendre que les threads aient tous fini et puis les recréer serait trop lent dans mon implémentation, parce qu'il faut à chaque fois répartir entre les threads les calculs à faire. Ici, au lancement du programme les threads sont crées avec leurs calculs à faire assignés et ils itèrent la dessus en attendant les autres à chaque fois).
En faisant des tests, il se trouve que locker chaque thread semble un peu plus rapide que locker le manager.
J'avoue avoir une compréhension assez approximative de wait et notify donc j'ai un peu peur du deadlock ou de mal m'y prendre. :?
java.util.concurrent.CyclicBarrier ?
Je ne peux pas l'utiliser :D
C'est pour cela qu'il me faut choisir entre les deux solutions mentionnées :)
Et pourquoi donc? C'est un exercice? :)Citation:
Envoyé par romit
C'est un projet dans lequel je ne peux pas utiliser CyclicBarrier :)
Vous me confirmez donc que le mieux est de locker le manager plutôt que chaque thread ?
oui, c'est sur le manager (ou en tout cas une seul objet commun unique, peu importe lequel), qu'il faut que tous les threads fassent un wait afin d'être réveillés sur le notifyall.
Parfait, merci à vous !