jai 2 threads :
une qui executre 100 fois Add(int) et l'autre 100 fois Vote()
les deux threads activent une methode sur un objet de type File
c le meme objet, passé par argument lors de lappel au constructeur des threads
 
le probleme est que le premier thread reste bloque sur le wait tandis que lautre avance toute le temps et fait ces 100. c seulement a ce moment que lautre thread demarre et fait les votes

T'es sur qu'il est bloqué le premier ?
 
C'est pas plutôt qu'il est débloqué mais que le processeur n'a aucun intérêt à lui donner la main tant que l'autre n'est pas fini pour diminuer le nombre de changement de contexte ?
 
(je ne vérifie pas tes synchronised car j'en ai marre de lire la doc pour les autres, mais à l'intuite j'aurais dit que c'est toute la classe qui devrait être "synchronised" ).

 
jai fait un system.out.println apres le wait et il na pas marche pas. dans le 1er thread (celui avec les add javais mit un Thread.sleep(10000); et ca marche qd meme pas  

ah oui, non, je viens de capter (tu fais un sémaphore privé) tu fais ton sleep dans la méthode synchronised, donc avec le lock.

lobjet file est créé dans mon main puis passé comme argument a mes thread ca pose un prob ????

non, le problème c'est que tu fais le sleep dans la méthode add() alors qu'il faut le faire à l'extérieur.

 
je viens juste de le trouver merci bien qd meme  

ok, mais après le sleep, la méthode add se termine => le lock est libéré => l'autre thread devrait prendre la main puisqu'il est en attente ...
je trouve quand même bizarre que l'autre Thread ne reprenne jamais la main ...

bah non, il a le proc, il a du boulot, il a rien qui l'empêche d'avancer, il a pas consomé beaucoup de temps (le sleep ne compte pas, car il s'est fait dégager pendant ce temps là), un switch ça coûte cher. Alors que l'autre dort, n'est réveillable que depuis peu et n'est nécessaire à personne pour que ça avance.
 
edit : je pense pas qu'une sortie de méthode soit un point de décision pour l'ordonnanceur, par contre, une petite entrée-sortie ça peut faire basculer.

c'est pas que depuis peu, c'est systématiquement 100 fois de suite !

 
voila la version finale, marche nikel

bon euh drapeau.

Bah oui, mais à chaque fois que notre ami voteur aurait la possibilité d'être débloqué parceque monsieur ajouteur est en rade sur son timer, seigneur voteur peut pas se débloquer parce qu'il peut pas bouger le petit doigt de la section critique parceque l'ajouteur boulet la squatte.
 
100 fois de suite, à l'ocasion de prendre le processeur grâce à la notification et à l'arrêt de l'ajouteur, le voteur est bloqué parce que l'ajouteur dort dans la section critique.

ce que je comprend pas c'est que le voteur prenne pas la main au moment où l'ajouteur sort da la fonction (après le sleep). Là il a tout le loisir de prendre le lock le temps que l'ajouteur retourne dans la méthode d'ajout.

Parce qu'il ne reste pas assez de temps en dehors, et qu'il ne fait aucune action suceptible de déclencher un ré-ordonnancement en dehors. D'autant plus que ça fait très peu de temps qu'il a la main (sortie du sleep) quand il sort, il a donc un beau crédit-temps tout neuf à écluser alors que l'autre n'était pas prête à la dernière vérification.

Si je comprends bien, c'est beaucoup plus intelligent de faire des :

et des

que de déclarer les méthodes synchronisées, pour ce qui est synchronisation de threads.
 
Pour l'accès à des ressources critiques, c'est différent, évidemment, mais ça doit pouvoir se régler indépendamment par un :

On peut aussi mieux faire : synchroniser sur un objet créé spécialement pour ça. Cela évite ainsi d'interférer avec d'autres objets qui auraient la mauvaise idée d'utiliser ton objet pour synchronizer autre chose.