Discussion :

[the_ionic]

Salut,
je sais qu'il existe ces merveilleuses méthodes wait(), et notifyAll() associées aux mots clés synchronized pour gérer tout ce qui concerne la synchronisation de thread en java mais j'ai besoin d'une confirmation quant à une de mes intérrogations.

On ne peut pas utiliser un booléen pour synchroniser deux threads? En gros, les deux threads partages un booléen (synchronized) et le thread A, doit attendre que le thread B passe le booléen à true pour continuer un traitement.

Donc j'ai en gros pour thread A:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
public void run() {
		try {
			while(true)
                       {
                                 while(!objetPartage.getBoolean())
                                {  
                                       // Je fais le traitement car B a fini
				}
                        }

Pour le thread B:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
public void run() {
		try {
			while(true){
                                 objetPartage.setBoolean(true); 
                        }

Y'a bien sûr du code dans le thread A et B et un traitement associé dans B pour pas qu'il fasse que mettre le booléen à true.
Mais bon, la question, c'est, est-ce mal de procéder comme cela? Et si oui pourquoi? Moi j'aimerai que ça soit mal mais j'en suis pas sûr...

Merci d'avance...

[CyberChouan]

Ton intuition est bonne: c'est plus mal que wait et notify!

Ta boucle infinie et le test du booléen vont être effectués continuellement jusqu'à ce que le booléen change de valeur: donc cela va consommer des ressources.
Le wait, au contraire, va "endormir" ton Thread et celui-ci ne va plus consommer de ressources jusqu'à ce qu'il soit réveillé par un "notify": c'est donc bien plus efficace (en terme de performances).

Parfois, deux threads doivent communiquer via des variables partagées: lorsque c'est le cas (comme dans ton exemple), tu ne dois pas oublier de déclarer ta variable (ici ton booléen) comme volatile. Sinon ton code pourrait s'avérer buggué et dans ton cas par exemple, le programme pourrait ne jamais effectuer le traitement.

La JVM peut décider, comme ton thread ne modifie pas le booléen, de mettre sa valeur en cache au lieux de le relire par soucis d'optimisation. Ainsi, lorsqu'un autre thread modifie sa valeur, celle-ci n'est pas prise en compte par le premier qui continue d'utiliser la valeur en cache.
Le mot-clé volatile force la JVM a raffraichir la variable à partir de sa valeur réelle (cf. la FAQ du site site sur les mots-clé).

[bredelet]

Ce code montre une attente active, ce qui occupe le processeur en permanence. Si c'est ton but pourquoi pas

Avec wait le thread s'interrompt jusqu'a ce qu'il puisse progresser a nouveau (notify). Donc le processeur peut s'occuper a d'autres taches pendant ce temps.

En tout cas CyberChouan doit avoir raison avec volatile, il faut se mefier des optimisations mal placees

[ndp]

Salut,

...
Parfois, deux threads doivent communiquer via des variables partagées: lorsque c'est le cas (comme dans ton exemple), tu ne dois pas oublier de déclarer ta variable (ici ton booléen) comme volatile. Sinon ton code pourrait s'avérer buggué et dans ton cas par exemple, le programme pourrait ne jamais effectuer le traitement.
...

entierement d'accord avec toi, excepte que la, en l'occurence, il n'y a pas besoin du mot cle volatile.

... En gros, les deux threads partages un booléen (synchronized) et le thread A, doit attendre que le thread B passe le booléen à true pour continuer un traitement.
...

[the_ionic]

Réponse parfaite, avec la précision du volatile en plus qui pourrait m'être utile par la suite.
Sincèrement merci!