Блокировка RW для потоков С++ 11

Я бы хотел использовать новые стандартные потоки вместо boost: threads, но я заметил, что старый shared_mutex недоступен. Что было бы хорошей рекомендацией по замене этой функции и дать мне блокировку с несколькими считывателями и одним писателем?

Ответ 1

std::shared_mutex будет частью стандартной библиотеки С++ 14. Он не попал на С++ 11 только потому, что не было времени, чтобы сформулировать предложение и обсудить его полностью.

Вы все равно можете использовать boost::shared_mutex. В Windows, если вы работаете с Windows Vista или более поздней версией, вы можете использовать Slim Read-Write Locks, которые оптимизированы для скорости и потребления памяти.

Ответ 2

Вы должны взглянуть на вопрос С++ 11, эквивалентный расширению shared_mutex ", и в частности следующий связанный разговор по электронной почте: http://permalink.gmane.org/gmane.comp.lib.boost.devel/211180 (что объясняет устойчивость комитета С++ 11 к одобрению shared_mutex). Также следующий эксперимент в блоге Джо Даффи: http://www.bluebytesoftware.com/blog/2009/02/12/ReaderwriterLocksAndTheirLackOfApplicabilityToFinegrainedSynchronization.aspx.

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

Является ли мой общий объект const? Я видел более неправильное использование shared_mutex в моей жизни, чем правильное использование. Чтобы правильно использовать shared_mutex, это должно быть так, что вы можете объявить свои общие объекты const внутри критического раздела читателя без каких-либо жалоб компилятора. "Потребитель" не эквивалентен "тому, кто вообще не мутирует структуру данных".
Являются ли мои критические разделы действительно длинными? Блокировка shared_mutex намного дороже, чем блокировка обычного мьютекса. Вы должны иметь большую работу в своем критическом разделе, чтобы компенсировать увеличение накладных расходов на приобретение/выпуск блокировки.
Должны ли мои критические разделы быть длинными? Вы должны спросить себя, действительно ли вам нужно делать все, что работает в критическом разделе. Часто есть куча подготовительной работы и/или работа по массажу возвращаемого объекта, окружающего вызовы const общему объекту. Большая часть этой дополнительной работы, которая не находится на пути зависимости от данных от первого использования общего объекта до последнего использования общего объекта, может перемещаться за пределы критического раздела.
Является ли нарушение блокировки моей проблемой производительности? Даже если ваши критические разделы длинны, вы должны быть абсолютно уверены, что конфликт блокировок - это действительно ваша проблема с производительностью. Если вы не сталкиваетесь с существенным конфликтом блокировки, тогда переход на блокировку чтения/записи не собирается ничего вам покупать.
Могу ли я уменьшить конфликт, перейдя на схему блокировки более мелкого зерна? Используете ли вы один замок для защиты нескольких объектов? Можете ли вы дать каждому объекту свой собственный замок?
Является ли отношение читателей к писателям значительно больше 1:1? Даже если ваши критические разделы длинны, и проблема блокировки является серьезной проблемой, отношение читателей к писателям должно быть чрезвычайно высоким, чтобы получить какую-либо выгоду от блокировок чтения/записи. Сумма зависит от затрат для атомных инструкций на вашем оборудовании и качества конкретных реализаций. (Джо Даффи считает, что на его машине ему нужно соотношение около 20: 1 читателей: писатели, чтобы заставить читателя/писателя блокировать победу.)