Le 14 Mar 2002 Guillaume Desnoix a �crit :
> Jean-Philippe Encausse wrote:
> > synchronize(this) {
> > try { wait(100); }
> > catch(InterruptedException e){ e.printStackTrace(); }
> > }
>
> C'est l'idee mais en synchronisant sur this, tu le bloques. Il faut
> mieux utiliser un autre objet dedie specifiquement au role de verrou.
>
Oui et non. Oui tu le bloques avec le synchronize, mais tu le
d�bloques pendant le wait. De toutes fa�ons tu as raison, il vaut
mieux utiliser un objet d�di� au r�le de verrou. A mon avis l'id�al
est une simple variable locale, comme dans ton exemple :
> Object o=new Object();
> try
> {
> synchronized(o) { o.wait(45000); }
> }
> catch(InterruptedException ex) { }
>
> (encore mieux, utiliser un recyclage du verrou).
>
> Enfin il faut mettre le tout dans une boucle si on veut garantir a
> 100% l'attente (au cas ou interrupt() est appele).
>
> Sinon j'utilise le plus souvent Thread.sleep() mais j'ai lu, je ne
> sais plus ou, que wait() etait preferable (car les verrous sont
> liberes durant l'attente). Qqn peut confirmer ?
>
Oui, je confirme. Le sleep ne passe pas forc�ment la main � un autre
thread, et ne lib�re aucun verrou. Heureusement, d'ailleurs, puisque
tu n'as pas besoin de verrou pour faire un sleep. Remarquez aussi que
rien n'emp�che un sleep de passer la main � un autre thread, il ne le
fait pas forc�ment, c'est tout.
--
Sur le Web, tout de suite.
Herve AGNOUX - diaam informatique
http://www.diaam-informatique.com
