Является ли ReaderWriterLockSlim правильным выбором?

Question

Я пишу глобальный обработчик ошибок / регистратор для приложений, работающих в Windows Azure. Когда в приложении возникает ошибка, выполняется ряд операций, которые должны выполняться атомарно. Мне нужно, чтобы ошибка не регистрировалась, пока предыдущая не будет завершена. Между тем, я хочу, чтобы чтения журналов происходили по мере необходимости.

Моя первоначальная мысль заключалась в использовании монитора / блокировки и блокировки только записей об ошибках. Таким образом, чтение вообще не блокируется. Мне было интересно, хотя будет ли более подходящим ReaderWriterLockSlim. Я не могу сказать, что действительно понимаю значение между одним подходом и другим.

Должен ли я создать ReaderWriterLockSlim и сделать что-то вроде следующего ниже (с чтениями, заключенными в EnterReadLock) ...

public static void LogError(Exception exception)
{
    _lock.EnterWriteLock();

    ...

    _lock.ExitWriteLock();
}

Или я просто делаю что-то вроде следующего, блокируя только секции записи:

public static void LogError(Exception exception)
{
     lock (someStaticLock)
     {
        ...
     }
}

Любые мысли / советы будут высоко оценены.

Answer 1

ОК, все зависит от того, как ожидается конфликт ресурсов. Ниже приводится простое решение, которое я бы принял на основании того, что я блокирую и сколько блокирую.

ReaderWriterLockSlim реализован с использованием спин-блокировки, поэтому, если у вас длинные ресурсы блокировки (в этом случае пишется текст), это приведет к ухудшению производительности из-за вращения из-за ожидающих потоков. Тем не менее, это очень полезный инструмент в следующих ситуациях.

• Если у вас много блокировок и каждая из них более мелкозернистая (блокировки для очень маленьких кусочков кода), то ReaderWriterLockSlim или (spinlock).
• Ожидаемое число потоков или конфликтов при высокой спин-блокировке имеет смысл при условии, что блокировка мелкозернистая.

Блокировка или монитор лучше всего подходят, когда ваши раздробленности грубы, и вы знаете, что разногласия или количество блокировок ниже.

ReaderWriterLockSlim сравнительно быстрее, чем ReaderWriterLock по крайней мере в 3-5 раз.

Answer 2

Почему вы не используете Очередь для хранения исключений по мере их появления и выплевывания их в фоновом рабочем потоке?Тогда вы можете просто заблокировать enqueue / dequeue с каждой стороны.Окно для коллизий может быть достаточно маленьким, и все в порядке, если фактическая запись данных журнала позади, потому что порядок сохранен.Если вы хотите, вы можете поместить Исключение в некоторую коллекцию, которая включает метку времени, когда элемент был помещен в очередь, чтобы вы могли соответствующим образом поставить метку времени.

Answer 3

Ну, я думаю, вы не должны читать без блокировки, потому что вы можете читать, пока идет атомарная операция. ReaderWriterLock кажется лучше, так как он гарантирует, что ни один читатель не сможет войти, когда идет процесс записи.