Les différentes portées de Synchronized ?

Bonjour à tous.
Je n'est jamais utilisé (explicitement) de threads jusqu'à maintenant, et je suis conscient que c'est une sacrée lacune.
Je me suis donc mis à étudier leur fonctionnement, mais un flou persiste sur le mot-clé Synchronized.

1èrement, je n'ai pas trouvé de récapitulatif sur les différentes portées du mot-clé :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

// 1er cas : Synchronized Objet o; // 2ème cas : void uneMethode() { //instructions Synchronized (unObjet) {//instructions} // insrtuctions } // 3ème cas : Synchronized void autreMethode() {//instructions}

---

Est-ce tout ??

Appliqué à une méthode (y compris Static), j'en ai compris le fonctionnement, la documentation ne manque pas à ce propos. Mais dans les autres cas, je n'ai pas trouvé grand chose, et ne sais pas sur quoi et comment s'applique le verrou...

Quelqu'un pourrait-il me dire où trouver un résumé de tout cela (ou m'en faire un ;) ) ?

Autre petite question, avec Java 5.0 et notamment le package java.util.concurrent, n'est-on pas appelé à se passer de Synchronized ?

J'avoue n'avoir jamais entendu parler du 1er cas. Où l'as tu trouvé ?

Pour le deuxième, le verrou est simplement l'objet donné en paramètre (si l'on peut dire), et pour le troisième, le verrou est this.

Citation:

---

Pour le deuxième, le verrou est simplement l'objet donné en paramètre (si l'on peut dire)

---

Je me doutais bien que c'était quelque chose comme ça ;)
Plus précisément (toujours pour le cas 2), l'accès à unObjet est impossible tant que les instructions "synchronisées" ne sont pas terminées ? ou alors ce sont juste les méthodes synchronisées de unObjet qui sont bloquées durant l'exécution des instructions synchronisées ?

Pour le cas 1, je l'ai trouvé dans un petit tuto qui ne reparle plus de ce cas après...

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

synchronized objet   synchronized (expression){ ... }   public void nomMethode(String[] tableau) { synchronized (tableau){ // Instructions... } ... }

---

Citation:

---

Envoyé par marchand de sable

Autre petite question, avec Java 5.0 et notamment le package java.util.concurrent, n'est-on pas appelé à se passer de Synchronized ?

---

On pourrait effectivement se passer de syncronized si et seulement si on est sùr qu'à n'importe quel moment, il y a un unique thread en execution (à part l'EDT bien sùr). Mais dès que le nombre de thread est supérieur ou égal à deux, il devient très dur de se passer de syncronized.

Oups, j'avais l'impression que ce package permettait de gérer la synchronisation et les priorités des différents threads....
Décidément, il me reste du travail avant de maîtriser tout ça 8O

Sinon, pas de précisions (ou de liens) pour les cas 1 et 2 ?

Salut,


Le 1er cas n'est pas possible, et provoque une erreur de compilation...

Pour le second cas, le lock est simplement placé sur la référence de unObjet (un seul thread peut poser un lock sur la même référence en même temps)...

Citation:

---

Envoyé par marchand_de_sable

Oups, j'avais l'impression que ce package permettait de gérer la synchronisation et les priorités des différents threads....

---

C'est bien cela, mais cela offre des fonctionnalité avancées. Ce n'est pas pour autant que le mot clef synchronized devient inutile...

a++

Citation:

---

Envoyé par adiGuba

Le 1er cas n'est pas possible, et provoque une erreur de compilation...

---

OK, c'est noté.

Citation:

---

Envoyé par adiGuba

Pour le second cas, le lock est simplement placé sur la référence de unObjet (un seul thread peut poser un lock sur la même référence en même temps)...

---

Donc un autre thread peut accéder à unObjet tant qu'il ne tente pas de le "locker" lui aussi, c'est bien ça ?

Citation:

---

Envoyé par marchand_de_sable

Donc un autre thread peut accéder à unObjet tant qu'il ne tente pas de le "locker" lui aussi, c'est bien ça ?

---

C'est bien cela : l'utilisation d'un bloc synchronized n'empêche pas que d'autre Thread accède à l'objet directement. C'est à la charge du développeur de vérifier qu'il n'y ai pas d'accès concurrent à un objet partagé, par exemple en utilisant des bloc synchronized à chaque fois que l'objet est utilisé...

a++

OK merci :D

Cette fois, j'ai compris.
C'est bizard, le principe de ce mot-clé est au bout du compte assez simple, mais je trouve que les documentations à son sujet compliquent inutilement la chose... (enfin, ce n'est que mon impression)

Il ne me reste plus qu'à comprendre les subtilités de la gestion du cycle de vie des threads, et j'aurais fait un grand pas dans ma vie de programmeur du dimanche ;)

A+