C# verrouillage d'un objet qui est réaffecté dans le bloc de verrouillage

Question

J'ai ce code dans une classe:

private static MyObject _locker = new MyObject(); 

... 

lock (_locker) 
{ 
    ... 
    _locker = new MyObject(); 
    ... 
} 

Sera-t-garder le verrou sur _locker?

Answer 1

Non, ce ne sera pas le cas. A partir de la spécification C# (l'accent est à moi):

Une déclaration de verrouillage de la forme lock (x) ... où x est une expression d'un type de référence , est précisément équivalent à

System.Threading.Monitor.Enter(x); 
try { 
    ... 
} 
finally { 
    System.Threading.Monitor.Exit(x); 
} 

sauf que x est seulement évalué une fois.

Étant donné que x n'est pas réévalué, le verrou sera libéré.

Answer 2

Ne faites pas cela. Envisagez d'utiliser un objet séparé entièrement pour conserver l'état du verrou, pas nécessairement l'objet que vous souhaitez protéger dans l'instruction lock. Je vous écris souvent du code (ok, pas souvent) comme ceci:

private static readonly object _locker = new object(); 
private static MyObject _object; 
... 

lock (_locker) 
{ 
    ... 
    _object = new MyObject(); 
    ... 
} 

Il implique une sorte complètement différent du flux de programme que ce que vous regardez. lock() définit une section critique dans le code - vous ne l'utilisez pas comme un mécanisme de sécurité de thread polyvalent pour n'importe quel type d'objet (ce que je pense que votre intention est dans votre code?)

Answer 3

I Supposons qu'il conserve le verrou sur l'instance MyObject qui a été définie sur _locker lorsque lock a été appelée, c'est-à-dire qu'il conserve le verrou sur l'instance d'origine de _locker, et non sur l'instance MyObject nouvellement créée. Dans le code suivant, le verrou sera conservé sur MyObject("OriginalInstance") lorsque le lock est appelé pour la première fois. Lorsqu'il est appelé la deuxième fois, il se verrouille sur MyObject("NewInstance"). Par conséquent, le thread suivant peut entrer dans la section critique sans problèmes car la nouvelle instance n'est pas verrouillée.

Quoi qu'il en soit, faire des choses comme ça est généralement considéré comme une mauvaise pratique. Voir MSDN pour quelques conseils sur la façon d'utiliser lock.