Является ли ReaderWriterLockSlim.EnterUpgradeableReadLock () по сути тем же, что и Monitor.Enter ()? - PullRequest
3 голосов
/ 30 апреля 2010

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

Давным-давно я прочитал о ReaderWriterLock и прочитал о ReaderWriterGate, который пытается смягчить проблему, когда многие записи приходят с козырным чтением и ухудшают производительность. Однако теперь мне стало известно о ReaderWriterLockSlim ...

Из документов я считаю, что в любой момент в «режиме обновления» может быть только один поток. В ситуации, когда единственный доступ, который я использую, это EnterUpgradeableReadLock() (что подходит для моего сценария), тогда есть большая разница, если просто придерживаться lock(){}?

Вот выдержка:

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

Или рекурсивная политика имеет какое-либо значение для этого?

Ответы [ 2 ]

4 голосов
/ 30 апреля 2010

Согласовано. Если всем ваших потоков необходимо установить обновляемую блокировку чтения и , вы не можете позволить снять блокировку чтения и получить блокировку записи, тогда ReaderWriterLockSlim не является улучшением по сравнению с простой эксклюзивной блокировкой. Рекурсия не меняет этого. RWLS и необходимость избегать всегда существующей опасности тупиковой ситуации в значительной степени благоприятствуют модели, в которой один поток выполняет запись.

1 голос
/ 30 апреля 2010

У меня нет всех твоих ответов, но я попробую:

Оператор блокировки в c # является синтаксическим сахаром для вызова Monitor.Enter и Monitor.Exit. В результате только один поток может получить доступ к коду внутри блокировки одновременно.

lock()
{
  //only one thread can access this code at a time
}

Проблема в том, что многократное чтение безвредно, но блокировка () все равно блокирует. ReaderWriterLockSlim допускает многократное чтение, только одну запись. Это попытка повысить эффективность.

Политика рекурсии - это то, что вы должны указать - по умолчанию она отключена. Не слишком много знаю за этим, но надеюсь, что это немного поможет.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...