Discussion :

[jeje99]

Bonjour,

J'ai encore une question métaphysique sur Java :-p

Je vais m'expliquer avec du code :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
public class SemaphoreViteFait {
	Integer i = 0;
 
	public void pending() throws InterruptedException{
		synchronized (i) {
			while(i >0){
				wait();
				i++;
			}
		}		
	}
 
	public void oneMore(){
		synchronized (i) {
			i++;
			notify();
		}
	}
}

D'après la javadoc c'est de cette manière qu'il faut utiliser les wait et notify (http://java.sun.com/j2se/1.5.0/docs/...ct.html#wait()).


La question qui me ronge, à priori si un thread a appelé la méthode oneMore et est bloqué sur wait, comment un autre thread pourra le débloquer car il est bloqué par la barrière du synchronized ?

En rédigeant ce topic une autre question m'est venue, est ce que :

Code :

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

1
2
3
4
5
 
class toto{
   synchronised void methodeSynchronised(){
    }
}

C'est la même chose que :

Code :

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

1
2
3
4
5
6
7
 
class toto{
   void methodeSynchronised(){
       synchronised (this){
       }
    }
}

Et oui je cherche à maîtriser entièrement la gestion de thread en Java...

---> edit ma question était incompréhensible je remercie bidi d'avoir réussi la prouesse de la comprendre :-)

[bidi]

Tout simplement ça va marcher parce que le wait relache le lock...

Pour la seconde question, ces deux lignes reviennent exactement au meme, l'avantage de la seconde étant que tu peux affiner la granularité... :-)

[benratti]

La question qui me ronge, à priori si un thread à appeler la méthode oneMore et est bloqué sur wait, comment autre thread pourra le débloquéer car la barrière du synchronized ?

Cherche du cote de l'exclusion mutuelle... C'est pas un probleme typique java mais plus un probleme de semaphore.

Par exemple tu as deux semaphores S1 et S2. Imaginons que tu as deux processus A et B qui ont tous les deux besoins de S1 et S2, si A prend S1 et B prend S2, il y a un probleme, les deux sont en wait, et il y a blocage. Un moyen de resoudre ce probleme est de mettre un ordre sur les semaphores. Ainsi, dans mon exemple, A et B vont essayer de prendre le semaphore S1 en premier, il n'y aura qu'un des deux qui pourra le prendre, supposons que ce soit A. A peut prendre S2, B est en wait, mais cette fois si hors du semaphore donc plus de soucis, il ne bloque pas de ressource. Et dans un cas un peu different, si B avait pris un autre semaphore, disons S0, et bien A finira un jour par lacher S2 puis S1, donc pas de soucis.

[bidi]

heuuu... ??? je capte pas bien ce que ça vient faire ici cette réponse... c un truc pour empêcher un deadlock mais il n'en est nullement question ici...

[jeje99]

heuuu... Rolling Eyes ??? je capte pas bien ce que ça vient faire ici cette réponse... Very Happy c un truc pour empêcher un deadlock mais il n'en est nullement question ici..

Exactement, mon problème n'est pas lié à l'utilisation de sémaphore, je m'en servait juste comme exemple, je voulais comprendre exactement comment la JVM gère le mutitache afin de maîtriser au maximum le code multithread que je fais. (m'enfin cette question n'était pas super bien formulé cf. edit premier post)

Donc bidi, tu me dit :

Tout simplement ça va marcher parce que le wait relache le lock...

Je veux bien te croire (surtout quand les exemples de sun le confirme) et la javadoc :

The current thread must own this object's monitor. The thread releases ownership of this monitor and waits until another thread notifies threads waiting on this object's monitor to wake up either through a call to the notify method or the notifyAll method. The thread then waits until it can re-obtain ownership of the monitor and resumes execution.

J'avais survolé cette phrase, parceque je fesais pas le lien entre object's monitor et synchronised(i){}...

Enfin, je met un résolu histoire de classer l'affaire[/quote]