Was ist der Vorteil von Monitor.Enter (Objekt, ref bool) über Monitor.Enter (Objekt)?

Question

Nach der Sprachspezifikation lock(obj) statement; würde kompiliert werden:

object lockObj = obj; // (the langspec doesn't mention this var, but it wouldn't be safe without it) 
Monitor.Enter(lockObj); 
try 
{ 
    statement; 
} 
finally 
{ 
    Monitor.Exit(lockObj); 
} 

jedoch als kompiliert wird:

try 
{ 
    object lockObj = obj; 
    bool lockTaken = false; 
    Monitor.Enter(lockObj, ref lockTaken); 
    statement; 
} 
finally 
{ 
    if (lockTaken) Monitor.Exit(lockObj); 
} 

Das viel komplizierter als nötig zu sein scheint. Die Frage ist also, was ist der Vorteil dieser Implementierung?

Answer 1

Wie immer hat Eric Lippert dies bereits beantwortet:

Fabulous Adventures In Coding: Locks and exceptions do not mix

Answer 2

Kürzlich I "CLR via C#" zu lesen, dass es nicht wirklich ein Vorteil sein könnte. Der Grund dafür ist, dass der finally-Block die gesperrte Ressource immer freigibt, selbst wenn der try-Block aufgrund eines unerwarteten Fehlers beendet wurde. Das könnte die Ressource in einem undefinierten Zustand und zugänglich machen. Das Programm wird nicht blockieren, aber der Fehler kann viel subtiler und daher schwieriger zu finden sein.

Es hängt sicherlich von der Situation ab, aber ich denke, die aktuelle Implementierung von lock macht am meisten Sinn, wenn Ihre Priorität ist, Deadlocks aufgrund unerwarteter Unterbrechung von Threads an der schlechtesten Stelle zu verhindern.