¿Permanece bloqueado un objeto bloqueado si se produce una excepción dentro de él?

Question

En una aplicación de subprocesamiento C#, si tuviera que bloquear un objeto, digamos una cola, y si ocurre una excepción, ¿el objeto permanecerá bloqueado? Aquí está el pseudo-código:

int ii; 
lock(MyQueue) 
{ 
    MyClass LclClass = (MyClass)MyQueue.Dequeue(); 
    try 
    { 
     ii = int.parse(LclClass.SomeString); 
    } 
    catch 
    { 
    MessageBox.Show("Error parsing string"); 
    } 
} 

Según tengo entendido, el código después de la captura no se ejecuta - pero me he estado preguntando si se liberará el bloqueo.

Answer 1

Primero; ¿Has considerado TryParse?

in li; 
if(int.TryParse(LclClass.SomeString, out li)) { 
    // li is now assigned 
} else { 
    // input string is dodgy 
} 

El bloqueo se lanzará por 2 razones; primero, lock es esencialmente:

Monitor.Enter(lockObj); 
try { 
    // ... 
} finally { 
    Monitor.Exit(lockObj); 
} 

Segundo; captas y no vuelves a lanzar la excepción interna, por lo que el lock nunca ve una excepción. Por supuesto, está presionando el candado mientras dure un MessageBox, lo que podría ser un problema.

Por lo tanto, se lanzará en todas las excepciones irrecuperables pero catastróficas más mortales.

Answer 2

Solo para agregar un poco a la excelente respuesta de Marc.

Situaciones como esta son la verdadera razón de la existencia de la palabra clave lock. Ayuda a los desarrolladores a asegurarse de que se libere el bloqueo en el bloque finally.

Si está obligado a usar Monitor.Enter/Exit p. para admitir un tiempo de espera, debe asegurarse de realizar la llamada al Monitor.Exit en el bloque finally para garantizar la liberación adecuada del bloqueo en caso de una excepción.

Answer 3

"Una declaración de bloqueo se compila a una llamada a Monitor.Enter, y luego una oportunidad ... finally. En el bloque finally, Monitor.Exit se llama.

La generación de código JIT tanto para x86 y x64 asegura que un aborto de subprocesos no puede ocurrir entre una llamada de Monitor.Enter y un bloque de prueba que lo sigue inmediatamente ".

Tomado de: This site

Answer 4

sí, que dará a conocer adecuadamente; lock actúa como try/finally, con el Monitor.Exit(myLock) finalmente, por lo que no importa cómo salga será liberado. Como nota al margen, lo mejor es evitar catch(... e) {throw e;}, ya que eso daña el stack-trace en e; es mejor no atraparlo en absoluto, o alternativamente: usar throw; en lugar de throw e; que hace un nuevo lanzamiento.

Si realmente quiere saber, un bloqueo en C# 4/4 .NET es:

{ 
    bool haveLock = false; 
    try { 
     Monitor.Enter(myLock, ref haveLock); 
    } finally { 
     if(haveLock) Monitor.Exit(myLock); 
    } 
} 

Answer 5

Su bloqueo se libera correctamente. A lock actos como este:

try { 
    Monitor.Enter(myLock); 
    // ... 
} finally { 
    Monitor.Exit(myLock); 
} 

Y finally bloques están garantizados para ejecutar, no importa lo que salga del bloque try.

Answer 6

Observo que nadie ha mencionado en sus respuestas a esta pregunta anterior que liberando un bloqueo ante una excepción es algo increíblemente peligroso de hacer. Sí, las sentencias de bloqueo en C# tienen semántica "finalmente"; cuando el control sale de la cerradura normal o anormalmente, se libera la cerradura. Todos hablan de esto como si fuera algo bueno, ¡pero es algo malo! Lo correcto si tiene una región bloqueada que arroja una excepción no controlada es finalizar el proceso enfermo inmediatamente antes de que destruya más datos de usuario, no libere el bloqueo y continúe.

Mírelo de esta manera: supongamos que tiene un baño con un candado en la puerta y una fila de personas esperando afuera. Una bomba en el baño se apaga, matando a la persona que está allí. Su pregunta es "¿en esa situación se desbloqueará automáticamente la cerradura para que la siguiente persona pueda entrar al baño?" Sí, lo hará. Eso no es algo bueno. ¡Una bomba estalló y mató a alguien! La tubería probablemente se destruyó, la casa ya no es estructuralmente sólida y podría haber otra bomba allí. Lo correcto es sacar a todos lo más rápido posible y demoler toda la casa.

Quiero decir, creo que a través: si usted se trabó una región de código con el fin de leer de una estructura de datos sin que se mutó en otro hilo, y algo en esa estructura de datos inició una excepción, más probable es que es porque la estructura de datos está corrupta. Los datos del usuario ahora están en mal estado; no desea intente guardar datos de usuario en este punto porque está guardando datos corruptos. Solo termine el proceso.

Si bloqueó una región de código para realizar una mutación sin otro hilo leyendo el estado al mismo tiempo, y la mutación arroja, entonces si los datos no estaban corruptos antes, ahora es. ¿Cuál es exactamente el escenario que se supone que el bloqueo protege contra. Ahora el código que está esperando para leer ese estado se inmediatamente se le dará acceso al estado dañado, y probablemente se bloquee. Nuevamente, lo correcto es terminar el proceso.

No importa cómo lo cortes, una excepción dentro de un bloqueo es malas noticias. La pregunta correcta es "¿se limpiará mi cerradura en caso de una excepción?" La pregunta correcta es "¿cómo me aseguro de que nunca haya una excepción dentro de un candado? Y si lo hay, ¿cómo estructuraré mi programa para que las mutaciones vuelvan a los buenos estados previos?"