Cela fait absolument la meme chose et mon code est redondant sauf qu'il est plus clair dans mon cas (trop long a expliquer mais en gros les classes concernees utilise un objet commun pour faire le lock et peuvent etre "Locker/Unlocker" depuis une methode exterieur ce qui oblige a appeler Monitor...).
Sinon j'utilise lock.
Une autre question qui concerne lock cette fois. Dans la MSDN on peut lire:
In general, avoid locking on a public type, or instances beyond your code's control. The common constructs lock (this), lock (typeof (MyType)), and lock ("myLock") violate this guideline:
lock (this) is a problem if the instance can be accessed publicly. lock (typeof (MyType)) is a problem if MyType is publicly accessible. lock("myLock") is a problem since any other code in the process using the same string, will share the same lock.
Et j'avoue n'avoir absolument pas compris pourquoi lock(this) ne doit pas etre appele. Pourriez-vous avoir l'amabilite de m'expliquer pourquoi lock(this) ne doit pas etre appele svp ?
Merci.
-- Michael ---- http://michael.moreno.free.fr/ http://port.cogolin.free.fr/
Bonjour,
Pourquoi n'utilisez vous pas les lock ?
Cela fait absolument la meme chose et mon code est redondant sauf qu'il
est plus clair dans mon cas (trop long a expliquer mais en gros les
classes concernees utilise un objet commun pour faire le lock et
peuvent etre "Locker/Unlocker" depuis une methode exterieur ce qui
oblige a appeler Monitor...).
Sinon j'utilise lock.
Une autre question qui concerne lock cette fois. Dans la MSDN on peut
lire:
In general, avoid locking on a public type, or instances beyond your
code's control. The common constructs lock (this), lock (typeof
(MyType)), and lock ("myLock") violate this guideline:
lock (this) is a problem if the instance can be accessed publicly.
lock (typeof (MyType)) is a problem if MyType is publicly accessible.
lock("myLock") is a problem since any other code in the process using
the same string, will share the same lock.
Et j'avoue n'avoir absolument pas compris pourquoi lock(this) ne doit
pas etre appele.
Pourriez-vous avoir l'amabilite de m'expliquer pourquoi lock(this) ne
doit pas etre appele svp ?
Merci.
--
Michael
----
http://michael.moreno.free.fr/
http://port.cogolin.free.fr/
Cela fait absolument la meme chose et mon code est redondant sauf qu'il est plus clair dans mon cas (trop long a expliquer mais en gros les classes concernees utilise un objet commun pour faire le lock et peuvent etre "Locker/Unlocker" depuis une methode exterieur ce qui oblige a appeler Monitor...).
Sinon j'utilise lock.
Une autre question qui concerne lock cette fois. Dans la MSDN on peut lire:
In general, avoid locking on a public type, or instances beyond your code's control. The common constructs lock (this), lock (typeof (MyType)), and lock ("myLock") violate this guideline:
lock (this) is a problem if the instance can be accessed publicly. lock (typeof (MyType)) is a problem if MyType is publicly accessible. lock("myLock") is a problem since any other code in the process using the same string, will share the same lock.
Et j'avoue n'avoir absolument pas compris pourquoi lock(this) ne doit pas etre appele. Pourriez-vous avoir l'amabilite de m'expliquer pourquoi lock(this) ne doit pas etre appele svp ?
Merci.
-- Michael ---- http://michael.moreno.free.fr/ http://port.cogolin.free.fr/
S.B
"Michael Moreno" a écrit dans le message de news:
Bonjour,
Une autre question qui concerne lock cette fois. Dans la MSDN on peut lire:
In general, avoid locking on a public type, or instances beyond your code's control. The common constructs lock (this), lock (typeof (MyType)), and lock ("myLock") violate this guideline:
il est en fait indiqué qu'_en_général_, il faut éviter d'utiliser une instance publique ou un type publique lors d'un vérouillage mais que les constructions commune lock(this), lock(typeof(MyType)) et lock("myLock") violent "naturellement" cette directive.
lock (this) is a problem if the instance can be accessed publicly. lock (typeof (MyType)) is a problem if MyType is publicly accessible. lock("myLock") is a problem since any other code in the process using the same string, will share the same lock.
Je pense qu'il s'agit en fait d'une mise en garde, peut être un peu maladroite, du risque accru de dead-lock dans le cas de l'utilisation de ce genre de construction.
Personnellement, j'utilise plutôt des vérous privé :
public class X { private Object mutex = new Object();
public void foo() { lock(mutex) { .... } }
Et j'avoue n'avoir absolument pas compris pourquoi lock(this) ne doit pas etre appele.
En espérant que ma contribution aura permis d'éclaircir ce point.
-- Seb
"Michael Moreno" <michael.ToRemove.moreno@free.fr> a écrit dans le message
de news: mn.2bce7d61dc1c2eca.21643@free.fr...
Bonjour,
Une autre question qui concerne lock cette fois. Dans la MSDN on peut
lire:
In general, avoid locking on a public type, or instances beyond your
code's control. The common constructs lock (this), lock (typeof (MyType)),
and lock ("myLock") violate this guideline:
il est en fait indiqué qu'_en_général_, il faut éviter d'utiliser une
instance
publique ou un type publique lors d'un vérouillage mais que les
constructions
commune lock(this), lock(typeof(MyType)) et lock("myLock") violent
"naturellement" cette directive.
lock (this) is a problem if the instance can be accessed publicly.
lock (typeof (MyType)) is a problem if MyType is publicly accessible.
lock("myLock") is a problem since any other code in the process using the
same string, will share the same lock.
Je pense qu'il s'agit en fait d'une mise en garde, peut être un peu
maladroite,
du risque accru de dead-lock dans le cas de l'utilisation de ce genre de
construction.
Personnellement, j'utilise plutôt des vérous privé :
public class X {
private Object mutex = new Object();
public void foo() {
lock(mutex) {
....
}
}
Et j'avoue n'avoir absolument pas compris pourquoi lock(this) ne doit pas
etre appele.
En espérant que ma contribution aura permis d'éclaircir ce point.
Une autre question qui concerne lock cette fois. Dans la MSDN on peut lire:
In general, avoid locking on a public type, or instances beyond your code's control. The common constructs lock (this), lock (typeof (MyType)), and lock ("myLock") violate this guideline:
il est en fait indiqué qu'_en_général_, il faut éviter d'utiliser une instance publique ou un type publique lors d'un vérouillage mais que les constructions commune lock(this), lock(typeof(MyType)) et lock("myLock") violent "naturellement" cette directive.
lock (this) is a problem if the instance can be accessed publicly. lock (typeof (MyType)) is a problem if MyType is publicly accessible. lock("myLock") is a problem since any other code in the process using the same string, will share the same lock.
Je pense qu'il s'agit en fait d'une mise en garde, peut être un peu maladroite, du risque accru de dead-lock dans le cas de l'utilisation de ce genre de construction.
Personnellement, j'utilise plutôt des vérous privé :
public class X { private Object mutex = new Object();
public void foo() { lock(mutex) { .... } }
Et j'avoue n'avoir absolument pas compris pourquoi lock(this) ne doit pas etre appele.
En espérant que ma contribution aura permis d'éclaircir ce point.
-- Seb
Michael Moreno
Bonjour,
Je pense qu'il s'agit en fait d'une mise en garde, peut être un peu maladroite, du risque accru de dead-lock dans le cas de l'utilisation de ce genre de construction.
oui je crois que j'ai compris il me semble. En le faisant sur un membre prive non accessible depuis l'exterieur on evite d'avoir des locks commis depuis l'exterieur sur l'instance et depuis l'interieur de la classe ce qui effectivement reduit le risque d'un dead-lock.
En espérant que ma contribution aura permis d'éclaircir ce point.
Oui, merci !
--
----------------------------------------------
http://michael.moreno.free.fr/
Bonjour,
Je pense qu'il s'agit en fait d'une mise en garde, peut être un peu
maladroite,
du risque accru de dead-lock dans le cas de l'utilisation de ce genre de
construction.
oui je crois que j'ai compris il me semble. En le faisant sur un membre
prive non accessible depuis l'exterieur on evite d'avoir des locks
commis depuis l'exterieur sur l'instance et depuis l'interieur de la
classe ce qui effectivement reduit le risque d'un dead-lock.
En espérant que ma contribution aura permis d'éclaircir ce point.
Je pense qu'il s'agit en fait d'une mise en garde, peut être un peu maladroite, du risque accru de dead-lock dans le cas de l'utilisation de ce genre de construction.
oui je crois que j'ai compris il me semble. En le faisant sur un membre prive non accessible depuis l'exterieur on evite d'avoir des locks commis depuis l'exterieur sur l'instance et depuis l'interieur de la classe ce qui effectivement reduit le risque d'un dead-lock.
En espérant que ma contribution aura permis d'éclaircir ce point.
Oui, merci !
--
----------------------------------------------
http://michael.moreno.free.fr/
Oriane
"Michael Moreno" a écrit dans le message de news:
Bonjour,
[...]
In general, avoid locking on a public type, or instances beyond your code's control. The common constructs lock (this), lock (typeof (MyType)), and lock ("myLock") violate this guideline:
lock (this) is a problem if the instance can be accessed publicly. lock (typeof (MyType)) is a problem if MyType is publicly accessible. lock("myLock") is a problem since any other code in the process using the same string, will share the same lock.
Et j'avoue n'avoir absolument pas compris pourquoi lock(this) ne doit pas etre appele. Pourriez-vous avoir l'amabilite de m'expliquer pourquoi lock(this) ne doit pas etre appele svp ?
Ben apparemment parce que le this est une instance publique dans ce cas, et que par conséquent qqn d'autre ayant la visibilité sur cet objet public peut être tenter de faire aussi un lock. Et là je ne fais que traduire ce qui est écrit !!
Le mot-clef "this" n'est pas un pb en soi.
Cdt
"Michael Moreno" <michael.ToRemove.moreno@free.fr> a écrit dans le message
de news: mn.2bce7d61dc1c2eca.21643@free.fr...
Bonjour,
[...]
In general, avoid locking on a public type, or instances beyond your
code's control. The common constructs lock (this), lock (typeof (MyType)),
and lock ("myLock") violate this guideline:
lock (this) is a problem if the instance can be accessed publicly.
lock (typeof (MyType)) is a problem if MyType is publicly accessible.
lock("myLock") is a problem since any other code in the process using the
same string, will share the same lock.
Et j'avoue n'avoir absolument pas compris pourquoi lock(this) ne doit pas
etre appele.
Pourriez-vous avoir l'amabilite de m'expliquer pourquoi lock(this) ne doit
pas etre appele svp ?
Ben apparemment parce que le this est une instance publique dans ce cas, et
que par conséquent qqn d'autre ayant la visibilité sur cet objet public peut
être tenter de faire aussi un lock. Et là je ne fais que traduire ce qui est
écrit !!
In general, avoid locking on a public type, or instances beyond your code's control. The common constructs lock (this), lock (typeof (MyType)), and lock ("myLock") violate this guideline:
lock (this) is a problem if the instance can be accessed publicly. lock (typeof (MyType)) is a problem if MyType is publicly accessible. lock("myLock") is a problem since any other code in the process using the same string, will share the same lock.
Et j'avoue n'avoir absolument pas compris pourquoi lock(this) ne doit pas etre appele. Pourriez-vous avoir l'amabilite de m'expliquer pourquoi lock(this) ne doit pas etre appele svp ?
Ben apparemment parce que le this est une instance publique dans ce cas, et que par conséquent qqn d'autre ayant la visibilité sur cet objet public peut être tenter de faire aussi un lock. Et là je ne fais que traduire ce qui est écrit !!
