ReaderWriterLock по сравнению с блокировкой {}
Определение неопределенного поведения в каждом стандарте C и C ++ заключается в том, что стандарт не налагает никаких требований на то, что происходит.
Да, это означает, что любой результат разрешен. Но особых результатов, ожидаемых , не существует, и никаких результатов, которые не требуются , НЕ произойдет. Не имеет значения, есть ли у вас компилятор и библиотека, которые последовательно дают конкретное поведение в ответ на конкретный экземпляр неопределенного поведения - такое поведение не требуется и может измениться даже в будущей выпуске исправления вашего компилятора - и компилятор будет по-прежнему абсолютно корректным в соответствии с каждой версией стандартов C и C ++.
Если ваша хост-система имеет аппаратную поддержку в виде соединения с зондами, вставленными в ваши ноздри, она находится в пределах вероятность того, что возникновение неопределенного поведения вызовет нежелательные носовые эффекты.
6 ответов
Блокировка позволяет выполнить только один поток для выполнения кода в то же время. ReaderWriterLock может позволить нескольким потокам прочитать одновременно или иметь эксклюзивный доступ для записи, поэтому он может быть более эффективным. Если вы используете .NET 3.5 ReaderWriterLockSlim даже быстрее. Поэтому, если ваш общий ресурс читается чаще, чем написано, используйте READERWRITERLOCKSLIM . Хорошим примером для использования это файл, который вы читаете очень часто (по каждому запросу), и вы обновляете содержимое файла редко. Поэтому, когда вы читаете из файла, вы входите в замок чтения, чтобы многие запросы могли открыть его для чтения, и когда вы решите написать, вы введите блокировку записи. Использование блокировки в файле будет в основном означать, что вы можете служить один запрос одновременно.
Подумайте об использовании ReaderWriterLock, если у вас есть много потоков , которые только должны читать данные , и эти потоки блокируются в ожидании блокировки, и вам не нужно часто изменить данные.
Однако ReaderWriterLock может заблокировать поток, который ожидает записи в течение длительного времени.
Поэтому используйте ReaderWriterLock только после того, как подтвердите , вы получите высокий уровень конкуренции для блокировки в « реальной жизни » и подтвердили, что не можете изменить дизайн Ваша конструкция блокировки до сокращает время удержания блокировки в течение .
Также подумайте, если вы не можете лучше хранить общие данные в базе данных, и пусть она позаботится обо всей блокировке, так как с гораздо меньшей вероятностью вам будет трудно отследить ошибки, если база данных работает быстро. достаточно для вашей заявки.
В в некоторых случаях вы также можете использовать кэш Aps.net для обработки общих данных и просто удалять элемент из кеша при изменении данных. Следующее чтение может поместить новую копию в кеш.
Помните
«Лучший вид блокировки - это блокировка, которая вам не нужна (то есть не делите данные между потоками)».
ReaderWriterLock позволяет нескольким потокам одновременно удерживать ReadLock ... так что ваши общие данные могут использоваться многими потоками одновременно. Как только запрашивается WriteLock, больше ReadLocks не предоставляется, и код, ожидающий WriteLock, блокируется, пока все потоки с ReadLocks не освободят их.
WriteLock может удерживаться только одним потоком, поэтому ваши «обновления данных» могут выглядеть атомарно с точки зрения потребляющих частей вашего кода.
Блокировка, с другой стороны, позволяет входить только одному потоку за раз, без учета потоков, которые просто пытаются использовать общие данные.
ReaderWriterLockSlim - это новая, более производительная версия ReaderWriterLock с улучшенной поддержкой рекурсии и возможностью плавного перемещения потока из блокировки, которая по сути является ReadLock, в WriteLock (UpgradeableReadLock).
READERWRITERLOCK / SLIM специально предназначен для того, чтобы помочь вам эффективно блокироваться в сценарии с несколькими потребительскими / одним производителем. Это так с помощью оператора блокировки возможно, но не эффективно. RWL / S получает верх, имея возможность агрессивно скручивать, чтобы получить замок. Это также помогает избежать блокировки конвоев, проблемы с оператором блокировки, в котором нить отказывается от квартала потока, когда он не может получить блокировку, что делает его позади, потому что он не будет перенесен некоторое время.
Я бы предложил просмотреть через http: // www .albahari.com / Threading / part4.aspx # _reader_writer_locks . Он говорит о ReaderWriterLockSlim (который вы хотите использовать вместо ReaderWriterLock).
Монитор и лежащий в основе "синхронизатор", который может быть связан с любым объектом ссылки - лежащий в основе механизм под C#'s lock- поддерживают эксклюзивное исполнение. Блокировка может быть доступна только одному потоку. Это просто и эффективно.
ReaderWriterLock (или, в версии V3.5, чем лучше ReaderWriterLockSlim), тем более сложная модель. Избегайте, если вы не знаете , что она будет более эффективной (т.е. иметь измерения производительности для поддержки себя).
Лучшим видом блокировки является блокировка, которая вам не нужна (т.е. не обмениваться данными между потоками).