Разница в производительности между мьютексом и критической секцией в C ++

Я читал этот пост о различиях в производительности в C # между критическими секциями и мьютексами для данного тестового примера. Мне интересно, есть ли какая-либо дополнительная документация, которая дает накладные расходы на производительность для различных классов блокировки для приложения C ++, в частности, MFC, работающего на 32- или 64-битной платформе Windows?

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

Отсюда вопрос, знает ли кто-нибудь справочную документацию, касающуюся накладных расходов на производительность различных механизмов блокировки MFC на разных платформах Windows?


c++ performance locking mfc
person SmacL    schedule 10.10.2011    source источник
comment
Ответы на ваш связанный вопрос идеально подходят и для MFC. Потому что, как и классы C #, классы MFC (например, CMutex или CCriticalSection) являются не чем иным, как оболочкой соответствующей функциональности Win32.   -  person Christian Rau    schedule 10.10.2011
comment
Спасибо, Кристиан, я как бы ожидал этого, но мне было интересно, зависят ли результаты от языка, оборудования и т. Д. И есть ли какая-либо достоверная информация, касающаяся производительности. Согласно приведенному ниже ответу Марка Ингрэма, документация MS, предполагающая, что критические разделы работают лишь «немного быстрее», вводит в заблуждение.   -  person SmacL    schedule 10.10.2011

Ответы (3)


arrow_upward
6
arrow_downward

Насколько я понимаю, Win32 Mutex - это полноценный объект ядра. Это означает, что любой вызов Mutex будет включать системный вызов. Это часто делает кеш недействительным и, следовательно, может быть довольно дорогостоящим.

Критические разделы - это объекты на стороне пользователя, которые не используют ядро ​​в случаях, когда нет разногласий. Вероятно, это делается с помощью инструкции ассемблера x86 LOCK или подобного, чтобы гарантировать атомарность. Поскольку системный вызов не выполняется, он будет быстрее, но поскольку он не является объектом ядра, нет возможности получить доступ к критическому разделу из другого процесса.

person doron    schedule 10.10.2011
comment
Почти. Я думаю, что под ... из другого потока вы на самом деле имеете в виду ... из другого процесса. - person RobH; 10.10.2011
comment
Спасибо за информацию. Похоже, мне нужно самому провести несколько тестов на разных платформах и в разных условиях. - person SmacL; 10.10.2011
comment
Идея правильная, но ваша ссылка на инструкцию LOCK хоть и верна, но немного вводит в заблуждение. Пользовательский аспект мьютекса обычно выполняется с помощью функции сравнения и замены и atomic_increment. Тогда можно будет увидеть, была ли конкуренция, без вызова ядра. Если не было разногласий, вызов ядра не требуется. В случае конфликта требуется вызов ядра для ожидания / освобождения мьютекса. Страница руководства для системного вызова futex Linux - хорошее место для получения подробностей о такой системе (или коде мьютекса pthread). - person edA-qa mort-ora-y; 10.10.2011
comment
Я больше знаком с набором инструкций ARM. Для armv5 вы используете SWP, для armV6 и выше вы используете инструкции LDREX и STREX. с помощью: codemaestro.com/reviews/8 - person doron; 12.10.2011

arrow_upward
1
arrow_downward

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

Следствием того, что мьютекс доступен в нескольких процессах, является то, что доступ к нему должен контролироваться ядром.

person RobH    schedule 10.10.2011

arrow_upward
1
arrow_downward

Прочтите следующую статью поддержки от Microsoft: http://support.microsoft.com/kb/105678 .

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

Скорость. В обзоре синхронизации говорится следующее о критических разделах:

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

Тупик. В обзоре синхронизации говорится о мьютексах следующее:

Если поток завершается, не освобождая своего владения объектом мьютекса, мьютекс считается оставленным. Ожидающий поток может получить право собственности на брошенный мьютекс, но возвращаемое значение функции ожидания указывает, что мьютекс оставлен. WaitForSingleObject () вернет WAIT_ABANDONED для мьютекса, который был отменен. Однако ресурс, который защищает мьютекс, остается в неизвестном состоянии.

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

person Mark Ingram    schedule 10.10.2011
comment
Меня здесь интересует термин «немного быстрее», поскольку ответ Майкла в связанном сообщении предполагает, что это более чем в 20 раз быстрее. - person SmacL; 10.10.2011