Discussion :

[freakfm]

En fait j’ai une question banale pour les threads. C’est quoi la signification de « synchronized ». Est-ce qu’une méthode synchronized d’un class peut être exécuté seulement par un seul thread à la fois ? Dans ce cas à quoi ça sert « notifyall() » dans une méthode synchronisé si une seule méthode qui peut être déverrouiller (sachant quel a fait un « wait() » avant). Etc etc…

[enrikomic]

Le mieux c'est que t'ailles voir un tuto comme celui la :
http://alwin.developpez.com/tutorial/JavaThread/
ou celui la :
http://viennet.developpez.com/cours/java/thread/

[®om]

ou encore:
http://rom.developpez.com/java-synchronisation

[freakfm]

Est-ce que vous pouvez me donner ce que vous avez compris une méthode Synchronized (sans parler des wait). Et aussi sur comment ça marche le « notifyall ». Bien sur je vais voir les tutoriaux mais j’aime aussi avoir des repense à votre façon.
Thanks.

[®om]

Est-ce que vous pouvez me donner ce que vous avez compris une méthode Synchronized (sans parler des wait). Et aussi sur comment ça marche le « notifyall ». Bien sur je vais voir les tutoriaux mais j’aime aussi avoir des repense à votre façon.
Thanks.

Étant donné que c'est moi qui ai écrit le tuto dont j'ai mis le lien, c'est une réponse à ma façon lol

[freakfm]

Dans le tutorial vous avez dit:

« Les problèmes d'accès concurrents se règlent en JAVA à l'aide du mot clé synchronized, qui permet de déclarer qu'une méthode ou un bloc d'instructions est critique : un seul thread á la fois peut se trouver dans une partie synchronisée sur un objet. »

Donc je peut dire qu’une méthode ‘sychronized’ ne peut être exécuter que par un seul thread à la fois.

Si non dans les trois tutoriaux il y a just un micro exemple qui explique le fonctionement de « notifyAll » il y a que du code sans explication

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
21
22
23
24
25
26
27
 
//: Evenement.java
// Classe simulant la notion d'événement
//	S. Szulman 1998
public class Evenement
{
	private Boolean Etat; // etat de l'evenement 
	public Evenement() {
		Etat = Boolean.FALSE;
	}
	public synchronized void set() {
		Etat = Boolean.TRUE;
        // debloque les threads qui attendent cet evenement:
		notifyAll(); 
	}
	public synchronized void reset() {
		Etat = Boolean.FALSE;
	}
	public synchronized void attente() {
		if(Etat==Boolean.FALSE) {
			try {
				wait(); // bloque jusqu'a un notify()
			}
			catch(InterruptedException e) {};
		}
	}// fin attente
}// fin classe

cela ne me permet pas de comprendre.
En faite je vais expliquer dans le message suivant qu’est ce que j’ai pas compris

[freakfm]

Ce que je comprend pas c’est si notifyall() dévérous tous les wait des method synchronized alors est ce que ça veut dire tous simplement que les wait sont annuler mais seulement un seul thread qui va marché et les autres vont attendre?. Je pense que ça marche comme ça non ?

[adiGuba]

Salut,

Le comportement de wait() et notify() est assez bien décrit dans la javadoc...

Quand tu rentres dans un bloc synchronized, le thread courant prend un verrou qui empêche les autres threads de rentrer dans le bloc (ou tout autre bloc qui utiliserait le même verrou). Si un autre thread tente de récupérer le même verrou il sera mis en attente jusqu'à qu'il soit libre

Et lorsque tu utilises wait(), ce verrou est libéré par le thread courant avant de rentrer en sommeil : donc d'autres threads peuvent éventuellement utiliser ce même verrou

The thread releases ownership of this monitor and waits until another thread notifies threads waiting on this object's monitor

Lorsque le thread est réveillé par un notify() ou notifyAll(), il doit reprendre le verrou à nouveau avant de pouvoir continuer. Donc les threads se réveilleront réellement les uns après les autres selon la libération du verrou...

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.

a++

[freakfm]

Donc si j’ai bien compris, il y a un seul verrou pour une méthode synchroniser d’un class, si on fait wait, on a plus le droit d’avoir le verrou, si on est réveillé par notify ou notifyall, on aura le droit au verrou mais on va attendre notre tour (dans le cas de notify ça va être notre tour, dans le cas de notifyall on va attendre notre tour qu’on peut dire aléatoire)

[adiGuba]

Donc si j’ai bien compris, il y a un seul verrou pour une méthode synchroniser d’un class,

Le verrou correspond à la référence utilisé dans le bloc synchronized :

Code :

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

1
2
3
synchronized (verrou) {
      ...
}

Sachant que pour lorsque synchronized est utilisé sur une méthode, le verrou utilisé est la référence de l'objet courant (this) ou l'instance de Class représentant l'objet pour les méthodes static, par exemple :

Code :

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

1
2
3
4
5
6
7
8
9
public class MaClasse {
	public synchronized void method() {
		// ...
	}
 
	public static synchronized void staticMethod() {
		// ...
	}
}

Est équivalent à :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
public class MaClasse {
	public void method() {
		synchronized(this) {
			// ...
		}
	}
 
	public static void staticMethod() {
		synchronized(MaClasse.class) {
			// ...
		}
	}
}

si on fait wait, on a plus le droit d’avoir le verrou, si on est réveillé par notify ou notifyall, on aura le droit au verrou mais on va attendre notre tour (dans le cas de notify ça va être notre tour, dans le cas de notifyall on va attendre notre tour qu’on peut dire aléatoire)

Oui grosso modo c'est ca

a++

[freakfm]

Oui grosso modo c'est ca

OK, thanks