Re: java et 'synchronized' statement

Page principale

Répondre à ce message
Auteur: Yves Martin
Date:  
À: guilde
Sujet: Re: java et 'synchronized' statement
On Wed, 2013-06-19 at 14:22 +0200, Hugues Evrard wrote:
> ----- Mail original -----
> > De: "Frédéric" <frederic.mantegazza@???>
> > À: guilde@???
> > Envoyé: Mercredi 19 Juin 2013 13:44:23
> > Objet: java et 'synchronized' statement
> >
> > Bonjour,
> >
> > Est-ce que quelqu'un peut m'expliquer comment est utilisé l'argument
> > passé à
> > synchronized(), pour protéger une section de type mutex ?
>
> http://docs.oracle.com/javase/tutorial/essential/concurrency/locksync.html
> https://en.wikipedia.org/wiki/Monitor_%28synchronization%29#Implicit_condition_variable_monitors
>
> En bref, en java il y a un moniteur associé à chaque objet. Ce moniteur n'a qu'une seule variable de condition, et une seule file, ce moniteur sert de mutex. La fonction synchronized prend en argument n'importe quel objet et cherche à acquérir le lock avant d'exécuter la suite. A noter qu'il existe le mot-clé synchronized, qui si j'ai bien compris equivaut à synchronized(this) { <method body> }


Oui c'est bien l'équivalent quand ce modificateur est présent sur une
méthode d'instance - à quelques détails près notamment sur le traitement
des InterruptedException.

Pour une méthode de classe (donc avec le modificateur static),
l'équivalent est synchronized(this.getClass()) { ... }


> Ce modèle n'est pas très propre, cf un article de Per Brinch Hansen (créateur, avec T. Hoare, du concept de moniteur de synchro):
> http://brinch-hansen.net/papers/1999b.pdf
> L'abstract du papier donne le ton:
> "The author examines the synchronization features of Java and finds that they are insecure variants of his earliest ideas in parallel programming published in 1972-73. The claim that Java supports monitors is shown to be false. The author concludes that Java ignores the last twenty-five years of research in parallel programming languages."


Merci pour cette référence, je suis curieux de connaître le fond de sa
réflexion. Le multithreading dans Java n'est peut-être pas parfait mais
il est compréhensible facilement et il faut bien admettre que "ça
marche", vu le nombre de projets qui l'exploite. Certes les développeurs
s'en soucient peu maintenant que de nombreuses bibliothèques fournissent
des services de haut niveau adaptés à des besoins spécifiques.


Pourquoi tout objet Java dispose d'un moniteur ? Et bien d'abord parce
qu'une JVM est dé-facto multi-thread (main + gc au minimum), et que le
modificateur de méthode nécessite bien un tel objet "implicitement".
Certes, le compilateur aurait pu créé un moniteur au besoin mais
l'héritage pose des problèmes annexes difficiles à résoudre.

Je ne suis pas sûr mais je pense que le moniteur est là présent sur tout
objet aussi pour faciliter la réalisation du garbage collector...
J'imagine que lors du prototype de JVM, les concepteurs se sont vus
ajouter un moniteur "presque partout" et alors il est arrivé sur
java.lang.Object

--
Yves Martin