QAtomicInt vs. QMutex

[once_again_abc]

Что быстрее - обращение к переменной через QMutex.lock/unlock или к переменной типа QAtomicInt через testAndSetRelaxed?

[brankovic]

В лучшем для мьютекса случае обращение через test_and_set 'быстрее' в 2 раза (в мьютексе выполнится минимум 2 test_and_set независимо от реализации, но в не-линуксах может быть и больше). В худшем случае мьютекс  может быть сколь угодно медленнее. Но это большая и сложная тема, 'быстрее' тут почти бессмысленное понятие.

[once_again_abc]

В лучшем случае для мьютекса обращение через test_and_set 'быстрее' в 2 раза (в мьютексе выполнится минимум 2 test_and_set независимо от реализации, но в не-линуксах может быть и больше). В худшем случае мьютекс  может быть сколь угодно медленнее. Но это большая и сложная тема, 'быстрее' тут быстрее почти бессмысленное понятие.

есть общие практики использования того и другого? каковы критерии выбора в зависимости от ситуации?

[brankovic]

Правило номер 1: никогда не используйте атомарные операции
Правило номер 2: никогда не используйте атомарные операции
Правило номер 3: в реальном проекте за использование атомарных операций отрубают руки по локоть

Если серьёзно, то пару раз видел очень эффективное использования кода на атомиках, но 1. код не простой, 2. убедить коллег что имеет смысл с этим связываться ещё сложнее. Короче использовать надо только если вы точно знаете, что это что-то даст, например если треды много времени ждут в локах.

Кстати, ваш другой давешний вопрос про QSettings тоже можно решить атомиками, но решение с read-write локерами всё же предпочтительнее из-за простоты и наглядности.

[once_again_abc]

Правило номер 1: никогда не используйте атомарные операции
Правило номер 2: никогда не используйте атомарные операции
Правило номер 3: в реальном проекте за использование атомарных операций отрубают руки по локоть

как-то несерьезно. чем обоснованны эти правила?

Если серьёзно, то пару раз видел очень эффективное использования кода на атомиках, но 1. код не простой, 2. убедить коллег что имеет смысл с этим связываться ещё сложнее. Короче использовать надо только если вы точно знаете, что это что-то даст, например если треды много времени ждут в локах.

не понял ваш "например". не могли бы пояснить, что вы здесь имели ввиду?

[brankovic]

как-то несерьезно. чем обоснованны эти правила?

правила получены опытным путём. Обычно реализация даже простого алгоритма (например обычный стек) на атомиках занимает много времени и тянет за собой шлейф трудно исправимых багов.

Сравнение atomic vs. locks сводится к следующему: мьютексы использовать проще, атомики потенциально эффективнее. Дальше следует выяснить насколько эффективнее. Оказывается не сильно, скажем ускорение на 50% в специфических местах может дать 5 или 1% для всей программы. А сложность алгоритмов на атомарных операциях буквально в разы больше. На поддержку такого кода обычно нет ресурсов. Это с точки зрения бизнеса. Теперь с вашей личной точки зрения. Допустим вы убьёте 2 недели на ускорение программы на 1%, оно вам надо? Как правило нет.

Edit: но есть конечно implicit sharing, shared_ptr и прочие полезные вещи, которые без атомиков не реализуешь. Обычно их кто-то до вас уже реализовал, нужно просто воспользоваться.

например если треды много времени ждут в локах.

не понял ваш "например". не могли бы пояснить, что вы здесь имели ввиду?

Если в приложении есть мьютексы-боттлнеки, т.е. места где много тредов ждут один тред захвативший мьютекс или просто очень часто треды 'сталкиваются' (т.е. засыпают из-за занятости мьютекса). Находятся такие проблемы как профилированием, так и умозрительно, поскольку профилировать такое не всегда получается.

[once_again_abc]

...

Спасибо! 

[Igors]

..поскольку профилировать такое не всегда получается.

Ну вот зачем так на самое больное место?  

как-то несерьезно. чем обоснованны эти правила?

Спасибо!  

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

Код

C++ (Qt)
QMutexLocker locker(&theMutex);
theVector[0] = 1;
 

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

[Akon]

Есть задачи, где без атомиков очень плохо, например, подсчет ссылок, а в целом согласен с brankovic.

[once_again_abc]

да, кьютишные семафоры и мьютексы довольно медленная штука.
использовал QAtomicInt + QAtomicPointer для неблокирующего кольцевого буфера в консьюмер-продюсер алгоритме.

[BRE]

да, кьютишные семафоры и мьютексы довольно медленная штука.

Нет никаких "кьютишные семафоры и мьютексы"! Эти классы в Qt всего лишь врапперы над системными объектами.

[once_again_abc]

да, кьютишные семафоры и мьютексы довольно медленная штука.

Нет никаких "кьютишные семафоры и мьютексы"! Эти классы в Qt всего лишь врапперы над системными объектами.

я в курсе и это вообще то очевидно. зачем об этом говорить, да еще так(!) эмоционально? =)

[BRE]

я в курсе и это вообще то очевидно. зачем об этом говорить, да еще так(!) эмоционально? =)

Потому что уже надоело читать про тормозящие кьютешные треды, мьютексы и сокеты.

Насчет мьютексов... если их сравнивать с атомарными операциями, то они всегда будут медленней последних, но и задачи они выполняют разные.
Задачу можно постараться решить так, что бы время ожидания на объектах синхронизации было минимально и им можно было просто пренебречь.
Вот для примера, если посмотреть на то, что предлагает проверить Igors в посте # 7. Время расчета значения в каждом треде соизмеримо (в этом случае даже меньше) с временем помещения этого значения в вектор. Тут и пробовать ничего не надо, и так понятно что все нитки кроме одной будут просто ждать на мьютексе и мы получим не ускорение, а заметные тормоза.
Но если изменить алгоритм и каждой нитке указать диапазон вектора для заполнения, то они все сразу заработают параллельно не мешая друг другу (да и объекты синхронизации уже не понадобятся). Или каждая нитка может заполнить свой внутренний вектор порцией данных, а мотом под защитой мьютекса добавить его в общий вектор и вернутся к заполнению внутреннего.
В общем нужно стараться, что бы нитки больше работали и меньше взаимодействовали.

[BRE]

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

[Igors]

Насчет мьютексов... если их сравнивать с атомарными операциями, то ..

Мутекс блокирует нитки, атомарные операции нет, эти вещи не взаимозаменяемы. Поэтому их сравнение бессмысленно, как и название топика.  

Вот для примера, если посмотреть на то, что предлагает проверить Igors в посте # 7. Время расчета значения в каждом треде соизмеримо (в этом случае даже меньше) с временем помещения этого значения в вектор. Тут и пробовать ничего не надо, и так понятно что все нитки кроме одной будут просто ждать на мьютексе и мы получим не ускорение, а заметные тормоза.

Вот пока "и так все ясно" (т.е. не проверено, не прочувствовано на опыте) - толку никакого  
Насколько (во сколько раз) время расчета должно быть больше, чтобы мутекс на общем контейнере работал удовлетворительно? (напр 4 нитки, требуемый КПД хотя бы 300%). Что выигрывается с QReadWriteLocker  (напр соотношение 3 чтения и 1 запись)?  Но я так вижу это неинтересно проверять. Куда проще что-то прочитать/услышать и поддержать разговор напр так

да, кьютишные семафоры и мьютексы довольно медленная штука.

Но если изменить алгоритм и ..

Ну так это может быть очень недешево (с точки зрения написания)

Возвращаясь к теме - плохо что Qt имеет только "честный" мутекс (fair mutex). Во многих случаях удается успешно проскочить с нечестным (unfair который не останавливает нитку) вместо дорогостоящей переделки алгоритма.