C# ReaderWriter блокировка приоритета освобождения потока

Question

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

Самое подходящее решение для моей проблемы - использование блокировки считывателя, но этот article Джеффри Рихтера заставил меня усомниться в использовании таких замков. У меня гораздо больше читателей, чем писателей, но изменения автора следует применять как можно быстрее.

Сохраняется ли это по-прежнему в версии 4.5. Lockwriter lock? Я имею в виду приоритет потоков читателей над потоками писателей?

Answer 1

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

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

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

Из документации ReaderWriterLockSlim.EnterWriteLock():

Если другие потоки вошли в замок в режиме чтения, поток, который вызывает метод блоков EnterWriteLock, пока эти потоки не выходили режим чтения.

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

В этом отношении он отличается от ReaderWriterLock - это выглядит как одна из вещей, которые были исправлены.

Это о лучшем, что вы можете получить. Главное, чтобы читатели держали свои замки в кратчайшие сроки.

Также обратите внимание, что ни ReaderWriterLock, ни ReaderWriterLockSlim поддержка межпроцессных замков.