ce que je veux dire c'est que lorsque qu'un thread a pris un "reentrant lock" il peut le reprendre à tout moment, instantanément. ça se passe exactement pareil avec "l'ancien mécanisme" synchronized.
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
ce que je veux dire c'est que lorsque qu'un thread a pris un "reentrant lock" il peut le reprendre à tout moment, instantanément. ça se passe exactement pareil avec "l'ancien mécanisme" synchronized.
Super ca fonctionne!
cela dit j'aimerais juste comprendre pourquoi est ce que ma premiere recherche passait. Je ne pense pas avoir tout compris aux locks.
(Je vais quand même relire la javadoc)
ben la premiere recherche passe car personne n'a encore pris le lock et donc, bloqué la méthode... Donc la première entre dans le lock, bloque les autres objets qui veulent y accéder. Si un autre objet veut accéder à la recherche il doit attendre que le lock soit libéré ==> ce qui fait que, au finish, tout s'exécute séquentiellement plutot que simultanément :-)
Le lock est donc déclanché par le reveille de la condition sinon la premiere recherche ne passerait pas (et pas par gLock.lock() ). Mais dans ce cas a quoi ca sert de faire un lock et un unlock ?
Cela sert à bloquer le thread, car lorsqu'il rentre dans la méthode await() il libère le lock et s'endord... Lorsqu'il recoit un signal, il récupère le lock (dès qu'il est disponible) pour continuer...Envoyé par addack
Cela permet de mieux controler le sommeil de ton thread...
Je ne l'ai pas encore vraiment utilisé, mais l'API de concurrence de Java 5.0 est vraiment intérressante, et cela ferais une bonne question dans la FAQ
a++
Merci !
Répondre avec citation
Partager