Сравнение Win32 CMutex и стандартной библиотеки std::mutex

С момента появления библиотеки thread в C++11 я просматривал свой код, внося некоторые изменения, чтобы переместить его из многопоточного кода, специфичного для платформы, в код переносимой стандартной библиотеки.

Однако меня интересует, есть ли разница в производительности или функциональности между стандартной библиотекой std::mutex и std::lock_guard<std::mutex> и специфическими для Win32 CMutex и CSingleLock.

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


c++ winapi c++11 mutex standard-library
person Thomas Russell    schedule 31.05.2013    source источник
comment
Кстати, CMutex и CSingleLock взяты не из Win32, а из MFC, сторонней библиотеки C++, которая является оболочкой для Win32. C-API. Хотя на практике, вероятно, существует совпадение 1-к-1 между CMutex и базовым мьютексом Win32.   -  person Christian Rau    schedule 31.05.2013
comment
@ChristianRau MFC не является сторонней организацией: она написана Microsoft.   -  person rubenvb    schedule 31.05.2013
comment
@rubenvb Тем не менее, это не более чем оболочка вокруг Win32 и никак с ней не связанная. Просто две стороны, разработавшие эти две вещи, работали на одну и ту же компанию.   -  person Christian Rau    schedule 31.05.2013

Ответы (1)


arrow_upward
5
arrow_downward

Функциональное почтение обязательно -- CMutex сопоставляется непосредственно с типом мьютекса Win32, в то время как std::mutex является более простым, вероятно, реализованным с использованием win32, CRITICAL_SECTION удаляя рекурсивный характер и std::recursive_mutex обертывая CRITICAL_SECTION. Они будут работать аналогично CCriticalSection.

CMutex — это тяжеловес, который на практике используется для создания именованных мьютексов для межпроцессного взаимодействия. Вы не должны использовать его внутри процесса.

Если ваш вопрос касается сравнения recursive_mutex и CCriticalSection, я бы сделал ставку на практически одинаковую производительность. С точки зрения интерфейса CSingleLock имеет совершенно мертвый интерфейс (он принимает второй аргумент, который по умолчанию равен FALSE вместо TRUE), поэтому на практике я никогда не использовал его напрямую, только через макрос, чтобы избежать ошибки.

В новом коде я бы сначала попытался решить проблемы, используя std::future, и возиться с блокировками только в крайнем случае. Многопоточность C++11 имеет смысл использовать, поэтому до тех пор, пока вам не понадобится функциональность CMultiLock, лучше. Я еще не исследовал, как покрыть последний случай, но был бы удивлен, если бы это нельзя было сделать легко.

person Balog Pal    schedule 31.05.2013