SemaphoreSlim.Wait (CancellationToken) правильно попробовать / наконец для OperationCancelledException? - PullRequest
8 голосов
/ 04 июня 2011

Как мне структурировать try / finally при использовании SemaphorSlim с токеном отмены так, чтобы OperationCancelledException обрабатывался правильно?В варианте A при отмене источника токена генерируется исключение OperationCancelledException, но не вызывается Release ().В варианте B при отмене источника токена генерируются исключение OperationCancelledException и DOES, вызывающий Release ().

// option A:
_semaphorSlim.Wait( _cancellationTokenSource.Token );
try
{
     // do work here
}
finally
{
     _semaphorSlim.Release();
}


// option B:
try
{
     _semaphorSlim.Wait( _cancellationTokenSource.Token );
     // do work here
}
finally
{
     _semaphorSlim.Release();
}

Ответы [ 2 ]

7 голосов
/ 04 июня 2011

Вариант А здесь более правильный.Вам не нужно Release SemaphoreSlim при отмене, поскольку вы фактически никогда не получаете и не увеличиваете его счет.Таким образом, вы не хотите выпускать, если ваш Wait вызов фактически не был успешным.Программист несет ответственность за то, чтобы поток не выпускал семафор слишком много раз.Например, предположим, что семафор имеет максимальное число, равное двум, и что поток A и поток B оба входят в семафор.Если из-за ошибки программирования в потоке B он дважды вызывает Release, оба вызова завершаются успешно.Счетчик семафора полон, и когда поток A в конце концов вызывает Release, генерируется исключение SemaphoreFullException.

0 голосов
/ 08 сентября 2014

-Извините за поздний ответ, надеюсь, это может кому-то помочь. Поскольку мы не можем гарантировать момент отмены и когда этот код может быть задействован, нам нужно использовать опцию A. Затем в предложении finally проверьте, использовался ли токен отмены или нет. Если он был использован, не освобождает семафор.

...