Bonjour à tous
 
Voilà, j'ai une classe pour laquelle j'utilise l'interface Runnable, pour pouvoir gérer des threads multiples.
J'avais quelques bugs, que je pense dûs à des accès simultanés par plusieurs threads à un même objet. Donc forcément, je regarde ma doc, et je tombe sur synchronized()
Je fais donc un truc du genre
 
synchronized(a) {
    synchronized(b) {
        a.methode(b);
    }
}
 
mais là, je constate que mon programme se bloque maintenant (ça freeze) ... quelqu'un aurait-il une explication possible à me donner ???

deadlock ?

Je ne sais pas ... je ne vois pas pourquoi ... j'ai pas de boucles infinies ... il y a même pas de boucles dans la méthode en question, juste du If et du Else :s Franchement, c'est dur de faire plus simple ...
Si un thread attend indéfiniment sont tour, j'avoue que je ne vois pas pourquoi

Fuadrait voir ton code mais si t'as 2 objets qui essaient de se synchroniser l'un par rapport à l'autre avec des prises de lock inversées, ça peut bloquer.

je crois que je vois l'idée ...
Parmi les threads que j'ai lancés, il y en a un qui appellera
 
synchronized(a) {  
    synchronized(b) {  
        a.methode(b);  
    }  
}  
 
et un autre qui est susceptible de faire
 
synchronized(b) {  
    synchronized(a) {  
        b.methode(a);  
    }  
}  
 
mais dans ce cas, pourquoi on n'a pas juste une attente de liberation des objets utilisés par le 1er thread servi ???

parce que si le premier thread prend a et attend b alors que le second prend b en attendant a, ils risquent de s'attendre longtemps (étreinte fatale).

Comment faire alors, pour préciser un ordre d'exécution explicite ??? Car les deux actions doivent être effectuées quand même

si tu es dans un dans un IDE passe en mode débug et quand tu programme se bloque met le en pause et regarde où sont bloqués tes threads. Sinon, si tu lances ton prg dans un shell, tu peux envoyer un signal au process pour lui demander d'afficher les stacktrace des threads. Mais je ne me souviens plus de la commande Ctrl+ kekchose ...

tu rajoutes un 3ème objet qui sera synchronyzed par tes 2 taches avant de tenter de locker a ou b par exemple.  
 

 
 
Ou alors tu change complètement de pattern de synchronisation.

oki merci, ça a l'air de marcher ça... je vais filer ça à ma binôme, qui a l'art de faire planter mes progs Comme ça je serai vite fixé Mici m'sieur

la synchronisation, ça se teste pas, ça se prouve au papier/crayon/vérificateur de code.

boh, doit y'avoir moyen de faire des unit tests (certes un peu tordus mais bon)

oué, et tu fais comment la couverture là-dessus ?

j'ai dit "doit y'avoir moyen", pas "je sais comment faire"
 
mais c'est vrai que bon

Par des méthodes formelles, mais puisque l'on passe en formel, autant faire toute la preuve d'un seul coup.
 
J'ai déjà posté un lien sur un outil de ce type.

ctrol + pause?

 
c'est un truc à mettre dans la java faq ca !  
 
ce qui est sympa c'est quand tu as un deadlock, ca te l'indique

 
c'est toi qui me l a appris ce truc hein  
 
 
source

je me souvenais que j'avais aidé quelqu'un avec ce truc  
 
je me fais vieux, je perds la mémoire

j'ai edité

déjà a l'époque je m'en souvenais plus
 
faut dire que ca sert pas non plus tous les jours ce truc ...

en tout ca pour moi ce fut tres efficace

clair !
 
quand je me relis je me demande comment je suis arrivé à trouvé ton problème à partir de ca . j'étais en forme ce jour là

tu nous a tous epaté je crois

Le jour où je trouve une étreinte fatale dans un de mes logiciels, je suis pas près de dormir !
 
On fois qu'on en a trouvé une, qui prouve que c'est pas truffé de conneries ?

Faire des synchronized en cascade c'est jamais bon.
 
Il faudrait avoir un point d'entrée unique pour l'obtention de resources partagées.
 
 
 

Sinon je pense qu'en changeant l'ordre ça devrait marcher :
synchronized(a) {  
    synchronized(b) {  
        a.methode(b);  
    }  
}  
   
synchronized(a) {  
    synchronized(b) {  
        b.methode(a);  
    }  
}  
 
nan ?