Que fait une déclaration de verrouillage sous le capot ?

Question

Je vois que pour utiliser des objets qui ne sont pas thread safe, nous entourons le code d'un verrou comme ceci :

private static readonly Object obj = new Object();

lock (obj)
{
    // thread unsafe code
}

Alors, que se passe-t-il lorsque plusieurs threads accèdent au même code (supposons qu'il s'exécute dans une application Web ASP.NET). Sont-ils mis en file d'attente ? Si oui, combien de temps vont-ils attendre ?

Quel est l'impact de l'utilisation de verrous sur les performances ?

Answer 1

El lock est traduite par C# 3.0 comme suit :

var temp = obj;

Monitor.Enter(temp);

try
{
    // body
}
finally
{
    Monitor.Exit(temp);
}

En C# 4.0 cela a changé et il est maintenant généré comme suit :

bool lockWasTaken = false;
var temp = obj;
try
{
    Monitor.Enter(temp, ref lockWasTaken);
    // body
}
finally
{
    if (lockWasTaken)
    {
        Monitor.Exit(temp); 
    }
}

Vous pouvez trouver plus d'informations sur ce que Monitor.Enter fait ici . Pour citer MSDN :

Utilice Enter pour acquérir le Moniteur sur l'objet passé en paramètre. Si un autre thread a exécuté un Enter sur l'objet mais n'a pas encore exécuté l'opération correspondante Exit le courant actuel bloquera jusqu'à ce que l'autre l'autre thread libère l'objet. Il est légal pour le même thread d'invoquer Enter plus d'une fois sans elle blocage ; cependant, un nombre égal de Exit doivent être invoqués avant que les appels les autres threads en attente sur l'objet se débloquent.

El Monitor.Enter attendra infiniment ; elle pas temps mort.

Answer 2

C'est plus simple que vous ne le pensez.

Selon Microsoft : Le site lock garantit qu'un thread n'entre pas dans une section critique du code alors qu'un autre thread se trouve dans la section critique. Si un autre thread tente d'entrer dans un code verrouillé, il attendra, bloqué, que l'objet soit libéré.

El lock appels par mots-clés Enter au début du bloc et Exit à la fin du bloc. lock Le mot clé gère en fait Monitor à l'arrière.

Par exemple :

private static readonly Object obj = new Object();

lock (obj)
{
    // critical section
}

Dans le code ci-dessus, le thread entre d'abord dans une section critique, puis il se verrouille. obj . Lorsqu'un autre thread essaie d'entrer, il essaie également de verrouiller obj qui est déjà verrouillé par le premier fil. Le deuxième fil devra attendre que le premier fil libère le verrou. obj . Lorsque le premier fil s'en va, un autre fil va verrouiller obj et va entrer dans la section critique.

Answer 3

Non, ils ne sont pas en attente, ils sont en train de dormir.

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 à

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

Il suffit de savoir qu'ils sont en attente l'un de l'autre, et qu'un seul thread entrera dans le bloc de verrouillage, les autres attendront...

Monitor est entièrement écrit en .net, il est donc assez rapide, regardez aussi classe Moniteur con réflecteur pour plus de détails

Answer 4

Les verrous bloquent l'exécution du code contenu dans le bloc verrouillé par les autres threads. Les threads devront attendre que le thread à l'intérieur du bloc de verrouillage ait terminé et que le verrou soit libéré. Cela a un impact négatif sur les performances dans un environnement multithread. Si vous devez procéder ainsi, assurez-vous que le code contenu dans le bloc de verrouillage peut être traité très rapidement. Essayez d'éviter les activités coûteuses comme l'accès à une base de données, etc.

Answer 5

La partie de l'instruction de verrouillage ne peut être exécutée que par un seul thread, de sorte que tous les autres threads attendront indéfiniment que le thread qui détient le verrouillage ait terminé. Cela peut conduire à une impasse.