Version imprimable
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
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?
Non.Citation:
Envoyé par giova_fr
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.
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...).Citation:
Envoyé par nara20
cf. ton autre discussion sur le même thème
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)Citation:
Envoyé par nara20
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é)Citation:
Envoyé par nara20
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'objetCitation:
Envoyé par giova_fr
EDIT: grillé par Guulh... voilà ce qui arrive quand on ouvre plein d'onglets et qu'on y revient 1/2 heure plus tard :aie:
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
Effectivement, et c'est d'ailleurs étonnant car c'est maintenant déconseillé par Microsoft...Citation:
Envoyé par Pol63
http://msdn.microsoft.com/en-us/library/c5kehkcz.aspx
Citation:
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.
c'est bien ce qu'il me semblait avoir lu dans msdn aussiCitation:
Envoyé par tomlev
y sont forts chez microsoft ^^
Interressant !Citation:
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
Dans ce cas ca voudrait dire premier arrivé premier servi?
Que si l'on souhaite que les threads modifiants l'objet soient "prioritaires" sur les thread "accedant en lecture" à cet objet, lock n'est pas la bonne methode, qu'il faudrait plutot utiliser des mutex?
Tout ce qui est multithreading est formidablement bien expliqué ici
http://www.albahari.com/threading/part2.aspx#_Locking
Je te conseile fortement d'acheter son livre :mouarf:
Merci ! je vais me délecter de ces infos.
Je maitrise plutot mal le multithreading que je fuis comme la peste tant que possible (et ai de gros probleme de freeze sur mon projet actuel).
J'aimerai bien mettre la main sur quelques patterns qui me permettraient de résoudre les problématiques les plus courrantes.
Citation:
Envoyé par giova_fr
merci de lire ceux qui prennent le temps de répondre, j'ai donné cette réponse : readerwriterlock
Désolé de t'avoir froissé "plus de performances" ne signifiait pas pour moi role différent d'un lock :)
Merci à tous pour vos réponses.
Merci aussi à tomlev pour cet article qui explique bien la démarche de Microsoft.
Je pense donc utiliser lock(maListe) et abandonner l'utilisation de SyncLock...