Herve AGNOUX wrote:
>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 :
>
toujours dans la m�me id�e
dans le bouquin deb peter HAGAR prtical java il conseille
Byte[] lock =new Byte[0];//l'objet le moins couteux selon lui (a
decompiler pour voir;)
>
>>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
>
>
