В приложении потоковой передачи C #, если бы я заблокировал объект, скажем, очередь, и если произойдет исключение, останется ли объект заблокированным? Вот псевдокод:
int ii;
lock(MyQueue)
{
MyClass LclClass = (MyClass)MyQueue.Dequeue();
try
{
ii = int.parse(LclClass.SomeString);
}
catch
{
MessageBox.Show("Error parsing string");
}
}
Насколько я понимаю, код после перехвата не выполняется, но мне было интересно, будет ли освобождена блокировка.
Первый; вы рассматривали TryParse?
in li;
if(int.TryParse(LclClass.SomeString, out li)) {
// li is now assigned
} else {
// input string is dodgy
}
Блокировка будет снята по 2 причинам; во-первых, lock по сути:
Monitor.Enter(lockObj);
try {
// ...
} finally {
Monitor.Exit(lockObj);
}
Второй; вы перехватываете и не генерируете повторно внутреннее исключение, поэтому lock никогда не видит исключения. Конечно, вы удерживаете блокировку на время работы MessageBox, что может быть проблемой.
Так что он будет выпущен во всех, кроме самых фатальных, катастрофических, невосстановимых исключений.
Monitor.Enter и try встречается TheadAbortException: blogs.msdn.com/ericlippert/archive/2009/03/06/
- person Igal Tabachnik; 01.10.2009
Замечу, что никто не упомянул в своих ответах на этот старый вопрос, что снятие блокировки исключения является невероятно опасным делом. Да, операторы блокировки в C # имеют семантику «finally»; когда элемент управления выходит из замка нормально или ненормально, блокировка снимается. Вы все говорите об этом так, будто это хорошо, но это плохо! Правильный вариант, если у вас есть заблокированная область, которая вызывает необработанное исключение, - это завершить зараженный процесс непосредственно перед тем, как он уничтожит больше данных пользователя, а не освободить блокировку и продолжить работу .
Взгляните на это так: представьте, что у вас есть ванная с замком на двери и очередь людей, ожидающих снаружи. Бомба в ванной взорвалась, убив человека, находившегося там. Ваш вопрос: «Будет ли в этой ситуации замок автоматически разблокирован, чтобы следующий человек мог попасть в ванную комнату?» Да, это будет. Это нехорошо. Там просто взорвалась бомба и кого-то убили! Водопровод, вероятно, разрушен, дом больше не является прочным, и там может быть еще одна бомба. Правильнее всего будет вывести всех как можно быстрее и снести весь дом.
Я имею в виду, подумайте над этим: если вы заблокировали область кода, чтобы читать из структуры данных без ее изменения в другом потоке, и что-то в этой структуре данных вызвало исключение, шансы хорошие, что это потому, что структура данных повреждена. Пользовательские данные теперь испорчены; вы не хотите пытаться сохранить данные пользователя на этом этапе, потому что затем вы сохраняете поврежденные данные. Просто прекратите процесс.
Если вы заблокировали область кода, чтобы выполнить мутацию без одновременного чтения состояния другим потоком, и мутация выдает ошибку, то если данные не были повреждены раньше, это точно сейчас. Это именно тот сценарий, от которого предполагается защитить блокировку. Теперь коду, ожидающему чтения этого состояния, немедленно будет предоставлен доступ к поврежденному состоянию и, возможно, произойдет сбой. Опять же, правильное решение - прекратить процесс.
Как ни крути, исключение внутри блокировки - это плохие новости. Правильный вопрос - не «будет ли моя блокировка очищена в случае исключения?» Правильный вопрос: «Как мне убедиться, что внутри блокировки никогда не будет исключения? И если есть, то как мне структурировать свою программу, чтобы мутации возвращались к предыдущим хорошим состояниям?»
да, это выпустит правильно; lock действует как _2 _ / _ 3_, с Monitor.Exit(myLock) в finally, поэтому независимо от того, как вы выйдете, он будет выпущен. В качестве примечания, catch(... e) {throw e;} лучше избегать, так как это повреждает трассировку стека на e; лучше не ловить его вообще, или, альтернативно: используйте throw;, а не throw e;, который выполняет повторный бросок.
Если вы действительно хотите знать, блокировка в C # 4 / .NET 4:
{
bool haveLock = false;
try {
Monitor.Enter(myLock, ref haveLock);
} finally {
if(haveLock) Monitor.Exit(myLock);
}
}
Оператор блокировки компилируется для вызова Monitor.Enter, а затем для блока try… finally. В блоке finally вызывается Monitor.Exit.
Генерация JIT-кода как для x86, так и для x64 гарантирует, что прерывание потока не может произойти между вызовом Monitor.Enter и блоком try, который сразу же следует за ним.
Взято из: Этот сайт
Monitor.Enter и try, так что сразу следует за условием JIT нарушается.
- person CodesInChaos; 28.02.2012
Ваш замок будет разблокирован правильно. lock действует так:
try {
Monitor.Enter(myLock);
// ...
} finally {
Monitor.Exit(myLock);
}
И finally блоков гарантированно выполнятся, независимо от того, как вы покинете try блок.
Просто чтобы добавить немного к отличному ответу Марка.
Подобные ситуации и являются причиной существования ключевого слова lock. Это помогает разработчикам убедиться, что блокировка снята в блоке finally.
Если вы вынуждены использовать _3 _ / _ 4_, например для поддержки тайм-аута вы должны обязательно разместить вызов Monitor.Exit в блоке finally, чтобы гарантировать надлежащее снятие блокировки в случае исключения.
