Discussion :

[T`lash]

Je suis en train d'étudier la synchronisation et le verrou d'objet dans un bouquin quand tout à coup j'ai pensé à quelque chose qui n'était pas expliqué et vous pourrez peut-être m'aider à satisfaire ma curiosité :


On sait qu'un Thread pose un verrou sur un objet lorsqu'il invoque une de ses méthodes synchronisée et les autres Threads doivent attendre que le verrou soit levé pour pouvoir accéder à cet objet.

Maintenant imaginez que dans la méthode synchronisé invoqué soit invoqué une méthode synchronisée d'un autre objet ; bien entendu le Thread demande un verrou sur ce second objet.

Cependant, si ce second objet est déjà verrouillé par un Thread qui attend la levée du verrou du premier objet, est-ce que les deux Threads vont se bloquer indéfiniment ou est-ce que la JVM a prévu ce cas de figure et qu'un mécanisme pour sortir de cette situation vaseuse existe ?

[Luc Orient]

... ou est-ce que la JVM a prévu ce cas de figure et qu'un mécanisme pour sortir de cette situation vaseuse existe ?

Cette situation "vaseuse", comme vous dites s'appelle un verrou mortel ou une étreinte fatale (" Deadlock " ou " Deadly embrace " en anglais). Elle est connue depuis fort longtemps (les années 60/70 en gros) dans le domaine des systèmes d'exploitation, des SGBD et des moniteurs transactionnels. La nombreuse littérature informatique consacrée à ces sujets décrit tous ces phénomènes et les solutions possibles qui, parfois, ne sont pas triviales.

Je ne connais ni Java ni la JVM mais j'ose espérer que ce mécanisme propose effectivement une solution ...

[Amine_sas]

Il s'agit en effet d'un probleme classique des systemes d'exploitation. Il existe deux approches pour le traiter, une dite pessimiste consiste a supposer que chaque demande d'une ressource risque de mettre le groupe des threads ou processus dans une situation d'interblocage; une algorithme specifique est executé (ecrit par Dijkstra) pour effectuer les vérifications necessaires; on cas de succès, la ressouce est allouée.

l'autre approche, optimiste, consiste à allouer la ressource, puis en cas de probleme une procedure systeme de detection et guerison est executée et elle finit souvent par tuer un processus pour briser le cycle. elle est utilisée dans les systémes où les interblocages sont peu frequents.

cela dit, pour les systemes, mais pour la JVM je n'ai pas grandes idées.

[T`lash]

Il s'agit en effet d'un probleme classique des systemes d'exploitation. Il existe deux approches pour le traiter, une dite pessimiste consiste a supposer que chaque demande d'une ressource risque de mettre le groupe des threads ou processus dans une situation d'interblocage; une algorithme specifique est executé (ecrit par Dijkstra) pour effectuer les vérifications necessaires; on cas de succès, la ressouce est allouée.

[...]

Cette première solution doit être très gourmande en ressources si des tests fréquents doivent être exécutés.
C'est comme utiliser notifyAll plutôt que notify afin de ne pas laisser de Thread dans l'état bloqué, mais même si c'est plus contraignant pour ne pas oublier de Thread c'est moins gourmand d'utiliser notify que notifyAll et une batterie de tests.

[divxdede]

LA JVM ne fera rien pour toi, tes deux threads seront en interblocages.
Si un de ceux ci est l'EventDispachThread d'AWT alors ton application sera de plus freezé graphiquement.

[Patriarch24]

Cependant, si ce second objet est déjà verrouillé par un Thread qui attend la levée du verrou du premier objet, est-ce que les deux Threads vont se bloquer indéfiniment ou est-ce que la JVM a prévu ce cas de figure et qu'un mécanisme pour sortir de cette situation vaseuse existe ?

L'interblocage est définitif. Il faut s'assurer qu'il n'arrivera jamais. D'ailleurs, un seul et même thread peut très bien se bloquer tout seul comme un grand : l'utilisation de verrous de type réentrant permet d'éviter ce type d'interblocage.