Discussion :

[nara20]

Bonjour,

Dans une application multithreadé utilisant une List<T> générique nommé maListe, je voudrais savoir si j'ai plutot intéret à utiliser lock(maListe) ou lock(((ICollection)maListe).SyncRoot).

Est ce qu'un lock sur une collection diffère d'un lock sur un objet ?(Par exemple est ce qu'un lock sur une collection va faire aussi des "lock" sur les éléments de cette collection)

Coté mémoire un objet utilisé dans un lock sera-t-il "recyclé" normalement par le GC ?

Merci d'avance.

Nara20

[giova_fr]

le lock sur un objet empeche tout autre thread d'y acceder.
Cela implique donc que tout autre thread ne peut pas acceder à l'un de ses membres tel que SyncRoot
Donc mieux vaut faire un lock sur ta liste.

Concernant le GC je ne sais pas, peut etre que ca fait perdre un cycle, mais pourquoi cette question?

[Guulh]

le lock sur un objet empeche tout autre thread d'y acceder.

Non.

Le fait de locker un objet "obj" bloque juste d'autres threads qui voudraient locker ce même objet "obj".

lock (obj) ne bloque pas l'usage d'obj par les autres threads.

[tomlev]

Dans une application multithreadé utilisant une List<T> générique nommé maListe, je voudrais savoir si j'ai plutot intéret à utiliser lock(maListe) ou lock(((ICollection)maListe).SyncRoot).

Il me semble ça revient au même, du moins pour les collections génériques (pour les collections non génériques de .NET 1.0, je sais pas trop ce que ça change...).
cf. ton autre discussion sur le même thème

Est ce qu'un lock sur une collection diffère d'un lock sur un objet ?(Par exemple est ce qu'un lock sur une collection va faire aussi des "lock" sur les éléments de cette collection)

Non, du point de vue du lock, une collection est un objet comme un autre. Ca ne fait pas de lock sur chaque item (d'ailleurs je ne vois pas trop à quoi ça servirait)

Coté mémoire un objet utilisé dans un lock sera-t-il "recyclé" normalement par le GC ?

Oui, il n'y a rien de particulier à ce niveau là (mais a priori il ne sera pas recyclé avant que le lock soit relaché)

le lock sur un objet empeche tout autre thread d'y acceder.
Cela implique donc que tout autre thread ne peut pas acceder à l'un de ses membres tel que SyncRoot

Non, pas du tout : ça empêche tout autre thread d'acquérir un lock sur le même objet, mais ça ne l'empêche pas d'y accéder... Donc l'utilisation de lock ne suffit pas à "sécuriser" l'accès à un objet : il faut que tout le monde se mette d'accord pour acquérir le lock avant d'accéder à l'objet

EDIT: grillé par Guulh... voilà ce qui arrive quand on ouvre plein d'onglets et qu'on y revient 1/2 heure plus tard

[Pol63]

nous on instancie un new object dans une variable de classe pour le lock
dans le framework on voit beaucoup de lock(this)

sinon jette un oeil au readerwriterlock, dans certains cas ca amène plus de performances qu'un lock

[tomlev]

dans le framework on voit beaucoup de lock(this)

Effectivement, et c'est d'ailleurs étonnant car c'est maintenant déconseillé par Microsoft...

http://msdn.microsoft.com/en-us/library/c5kehkcz.aspx

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 because any other code in the process using the same string, will share the same lock.

[Pol63]

Effectivement, et c'est d'ailleurs étonnant car c'est maintenant déconseillé par Microsoft...

c'est bien ce qu'il me semblait avoir lu dans msdn aussi
y sont forts chez microsoft ^^