Un oggetto bloccato rimane bloccato se si verifica un'eccezione al suo interno?

In ac # threading app, se dovessi bloccare un oggetto, diciamo una coda e se si verifica un'eccezione, l'oggetto rimarrà bloccato? Ecco lo pseudo-codice:

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

A quanto ho capito, il codice dopo il fermo non viene eseguito, ma mi chiedevo se il blocco verrà liberato.

Primo; hai considerato TryParse?

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

Il blocco verrà rilasciato per 2 motivi; in primo luogo, lockè essenzialmente:

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

Secondo; catturi e non rilanci l'eccezione interna, quindi locknon vede mai effettivamente un'eccezione. Naturalmente, stai tenendo premuto il lucchetto per la durata di un MessageBox, il che potrebbe essere un problema.

Quindi verrà rilasciato in tutte le eccezioni irrecuperabili tranne le più fatali catastrofiche.

Noto che nessuno ha menzionato nelle risposte a questa vecchia domanda che rilasciare un blocco su un'eccezione è una cosa incredibilmente pericolosa da fare. Sì, le istruzioni lock in C # hanno la semantica "finalmente"; quando il controllo esce dalla serratura normalmente o in modo anomalo, la serratura viene rilasciata. Parlate tutti di questo come se fosse una buona cosa, ma è una brutta cosa! La cosa giusta da fare se si dispone di una regione bloccata che genera un'eccezione non gestita è terminare il processo malato immediatamente prima che distrugga più dati utente , non liberare il blocco e andare avanti .

Guardala in questo modo: supponi di avere un bagno con una serratura alla porta e una fila di persone che aspettano fuori. Una bomba nel bagno esplode uccidendo la persona lì dentro. La tua domanda è "in quella situazione il lucchetto verrà automaticamente sbloccato in modo che la prossima persona possa entrare in bagno?" Si lo farà. Non è una buona cosa. Una bomba è appena esplosa lì dentro e ha ucciso qualcuno! Probabilmente l'impianto idraulico è stato distrutto, la casa non è più strutturalmente solida e potrebbe esserci un'altra bomba . La cosa giusta da fare è far uscire tutti il ​​prima possibile e demolire l'intera casa.

Voglio dire, pensaci bene: se hai bloccato una regione di codice per leggere da una struttura dati senza che venisse mutata su un altro thread, e qualcosa in quella struttura dati ha generato un'eccezione, le probabilità sono buone che sia perché la struttura dati è corrotto . I dati dell'utente sono ora incasinati; non vuoi provare a salvare i dati utente a questo punto perché stai salvando dati corrotti . Basta terminare il processo.

Se hai bloccato una regione di codice per eseguire una mutazione senza che un altro thread leggesse lo stato nello stesso momento e la mutazione genera, allora se i dati non erano corrotti prima, sicuramente lo è ora . Che è esattamente lo scenario da cui la serratura dovrebbe proteggersi . Ora il codice in attesa di leggere quello stato avrà immediatamente accesso allo stato danneggiato e probabilmente si bloccherà. Ancora una volta, la cosa giusta da fare è terminare il processo.

Non importa come lo tagli, un'eccezione all'interno di una serratura è una cattiva notizia . La domanda giusta da fare non è "la mia serratura verrà pulita in caso di eccezione?" La domanda giusta da porsi è "come posso assicurarmi che non ci sia mai un'eccezione all'interno di una serratura? E se c'è, allora come strutturo il mio programma in modo che le mutazioni vengano riportate agli stati buoni precedenti?"

sì, verrà rilasciato correttamente; lockagisce come try/ finally, con il Monitor.Exit(myLock)infine, quindi non importa come esci, verrà rilasciato. Come nota a margine, catch(... e) {throw e;}è meglio evitare, in quanto ciò danneggia la traccia dello stack e; è meglio non prenderlo affatto , o in alternativa: usa throw;piuttosto throw e;che fare un rilancio.

Se vuoi davvero saperlo, un blocco in C # 4 / .NET 4 è:

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

"Un'istruzione lock viene compilata in una chiamata a Monitor.Enter, e quindi un blocco try ... finalmente. Nel blocco finalmente, viene chiamato Monitor.Exit.

La generazione del codice JIT sia per x86 che per x64 garantisce che non possa verificarsi un'interruzione del thread tra una chiamata Monitor.Enter e un blocco try che la segue immediatamente. "

Tratto da: Questo sito

Il tuo blocco verrà rilasciato correttamente. A si lockcomporta in questo modo:

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

E l' finallyesecuzione dei blocchi è garantita, indipendentemente da come esci dal tryblocco.

Giusto per aggiungere un po 'all'eccellente risposta di Marc.

Situazioni come questa sono la vera ragione per l'esistenza della lockparola chiave. Aiuta gli sviluppatori ad assicurarsi che il blocco sia rilasciato nel finallyblocco.

Se sei costretto a usare Monitor.Enter/ Exiteg per supportare un timeout, devi assicurarti di inserire la chiamata a Monitor.Exitnel finallyblocco per garantire il corretto rilascio del blocco in caso di eccezione.