Механизмы мьютекса

Question

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

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

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

Спасибо.

Answer 1

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

Answer 2

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

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

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

Например:

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

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

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

Answer 3

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

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

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