Блог

У нас есть проект, ориентированный на .NET 2.0 RTM (да, это должен быть .NET 2.0 RTM, у нас есть несколько ортодоксальных клиентов). И мне просто интересно, каковы недостатки ReaderWriterLock? Почему это так плохо, что все говорят «не используйте это, попробуйте использовать что-нибудь другое, например lock statement»? Если бы мы могли использовать .NET 3.5, я бы определенно использовал ReaderWriterLockSlim, но ReaderWriterLock меня немного пугают все эти предупреждения, поступающие отовсюду. Кто-нибудь измерял производительность или что-то еще? Если есть какие-то проблемы с производительностью, при какой полезной нагрузке мы можем с ними столкнуться?

Мы имеем классическую ситуацию с точки зрения ReaderWriterLock основной цели, то есть многократного чтения и редкой записи. Использование lock инструкции заблокирует всех читателей. Возможно, для нас это не такая уж серьезная проблема, но если бы я мог использовать ReaderWriterLock , я был бы более доволен. IMO внедрение нескольких мониторов — действительно очень, очень плохая идея.

Следующие несколько сообщений могут дать вам идеи, которые вы ищете.

Сравнение производительности ReaderWriterLockSlim с ReaderWriterLock

Рико Мариани об использовании ReaderWriterLock часть в этом посте объясняются некоторые затраты и сценарии использования ReaderWriterLock, также ознакомьтесь с частью 1 и частью 2

Джеффри Рихтер об альтернативе ReaderWriterLock

Если вы действительно сталкиваетесь с идеальным вариантом использования ReaderWriterLock (т. Е. много одновременных операций чтения и мало операций записи), тогда используйте его!

Если вы обнаружите, что это слишком медленно, есть альтернативы. Санджевакумар предоставил несколько ссылок в своем ответе. Я тоже приведу один в своем:
Методы низкой блокировки в действии: реализация блокировки чтения-записи

Я процитирую выводы из этой ссылки здесь:

1. Используйте блокировки reader-writer, как предлагалось в моей первой статье. Если выполнение блокировки является проблемой, используйте приведенную здесь реализацию в качестве замены для системы .NET.ReaderWriterLock. Не стесняйтесь использовать эту реализацию, пока Microsoft не исправит версию в своей библиотеке.
2. Спин-блокировки — действительно ценный метод с низким уровнем блокировки. Здесь были использованы для создания чистой, простой, но эффективной блокировки чтения-записи, грамотно написанной в управляемом коде. Эта блокировка значительно проще, чем большинство реализаций, которые я видел, но при этом близка к оптимальной. Причина этого в том, что использование спин-блокировок ЗНАЧИТЕЛЬНО упрощает проектирование и анализ блокировки без ущерба для производительности. Не стесняйтесь использовать показанную здесь реализацию Spin lock для создания других высокопроизводительных параллельных конструкций.
3. Даже такая простая вещь, как блокировка чтения-записи, имеет свои тонкости в поведении (особенно если учитывать проблемы с производительностью). Простота здесь действительно окупается.