Структура синхронизации ConcRT против стандартной библиотеки
Если мое приложение предназначено для Windows и уже использует Concurrency Runtime в некоторых его частях. Есть ли преимущества / недостатки использования структур синхронизации ConcRT (concurrency:critical_section) по сравнению со стандартной реализацией библиотеки (std::mutex) вне задач ConcRT? (например, синхронизация асинхронных обратных вызовов WinAPI или управление доступом к данным между экспортированными функциями dll)
MSDN документация <mutex> утверждает, что он основан на ConcRT, но означает ли это, что внутреннее мьютекс использует критическое разделение и, следовательно, медленнее во всех ситуациях, что дает преимущество только в переносимости?
Или, наоборот, критическое_сечение разработано специально для использования с планировщиком ConcRT и является огромным излишним, когда используется с потоками ОС?
Постскриптум Этот вопрос касается всех структур синхронизации в среде выполнения с параллелизмом (crit_section, reader_writer_lock) & событие).
Также я пропустил WinAPI CRITICAL_SECTION, MUTEX, SRW и другие, считая их самыми быстрыми и легкими решениями (но не самыми красивыми).
Решение
Мне пришлось изменить мой std: mutex на concurrency :: crit_section, потому что он действительно ведет себя по-разному: когда мьютекс блокирует, он просто блокируется, когда критический_секция блокирует ConcRT запустит / повторно использует новый поток (если доступен). В моем случае я потерял много параллелизма из-за этой разницы до того, как переключился.
Увидеть http://msdn.microsoft.com/en-us/library/ff601929.aspx, «При возможности используйте конструкции совместной синхронизации»
Другие решения
Других решений пока нет …
detector