Механизмы Mutex

Question

Что является наиболее подходящим mutex alg в C# /. NET для такого рода задач.

• много читает
• несколько дополнительных изменений (до 3-х в «идти вперед» автомат)
• очень низкая вероятность столкновения (делает вероятность столкновения дело?).

Я думал о простой блокировке или ReaderWriterLockSlim, но я не уверен, какой из них выбрать, и если что-то лучше для этой задачи.

Спасибо.

Answer 1

Вам понадобятся собственные тесты. Я думаю, вы обнаружите, что в большинстве случаев простой старый lock будет быстрее, чем ReaderWriterLockSlim, даже если большинство доступов относятся к категории только для чтения. Причина в том, что накладные расходы на обслуживание блокировки намного выше. Прошло некоторое время с тех пор, как я сделал тесты, но я считаю, что ReadWriterLockSlim был примерно в 5 раз медленнее, чем lock. Очевидно, что удерживание блокировки дольше приведет к снижению общего влияния накладных расходов. В какой-то момент он перестает быть доминирующим фактором. Пробег будет варьироваться от одной ситуации к другой, поэтому собственный бенчмаркинг - вот лучший совет, который я могу здесь дать.

Answer 2

Я не знаю особенно о ReaderWriterLockSlim, но можно использовать мьютексу писателя-писателя , если нескольким чтениям разрешен доступ к критическому разделу параллельно. Если это предположение верно, это зависит от нашего варианта использования. Это часто, но не всегда так.

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

Что вы подразумеваете под «вероятностью столкновения» в этом контексте? Вероятность того, что два потока попытаются получить доступ к критическому разделу одновременно?

Answer 3

Хотя это старая нить (сообщение, что бы то ни было), я столкнулся с уникальным подходом к блокировке против MutEx, который при определенных обстоятельствах выгоден.

Если столкновения на нескольких лиц, желающих доступа нечасты, рассмотрим следующий подход:

• Acquire, с замком (ов) (мьютекс (ов) ...безотносительно), копии соответствующих данных
  • Убедитесь, что по крайней мере один из скопированных элементов достаточно, чтобы сравнить с оригиналом для того, чтобы обнаружить, была ли или нет произошло изменение
  • Выпуск замок (ы)
• Выполните манипуляции с копиями, снова сохраняя стабильного вашей деталь сравнения
• Acquire замок (ы)
• Compare ссылочного элемента с его оригиналом, чтобы определить, является ли изменение Произошла
• Если нет, то применить ваши результаты если да, то отказаться от результатов, повторно приобрести копии и начать
  • Отпустите фиксатор (ы)

Например:

1. Блокировка расчетного счета и сберегательного счета; приобретать копии обоих балансов и время последних транзакций; разблокировать
2. Рассчитать изменения ... например, перевести $ 5 от сбережений до проверки
3. Заблокировать учетные записи; сравните фактические и ваши копии сроков транзакции - если они совпадут, примените рассчитанные значения и разблокируют, если нет, повторно приобрести, разблокировать и перезапустить

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

Для этого существует некоторое аппаратное обеспечение, но оно больше не является «мейнстримом»: в IBM System 370 была приведена инструкция по атомному сравнению и обновлению только для этой ситуации.