Russian Qt Forum
Ноябрь 27, 2024, 06:53 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
 
  Начало   Форум  WIKI (Вики)FAQ Помощь Поиск Войти Регистрация  

Страниц: 1 [2]   Вниз
  Печать  
Автор Тема: Объясните идею Mutex :)  (Прочитано 10824 раз)
SimpleSunny
Гость
« Ответ #15 : Май 13, 2010, 20:15 »

Можно также посоветовать QReadWriteLock, если читать переменную будут несколько потоков, а запись производится редко.
« Последнее редактирование: Май 14, 2010, 00:45 от SimpleSunny » Записан
serg_hd
Хакер
*****
Offline Offline

Сообщений: 668



Просмотр профиля
« Ответ #16 : Май 13, 2010, 21:15 »

если этот контейнер после старта данных потоков(а) никем и никогда не изменяется, защищать не нужно.

И если при чтении данных из контейнера не изменяются никакие его внутренние переменные/поля/глобалы (что вполне возможно, и зависит от реализации конкретного контейнера)
Речь идёт о QList<QPair<QString, QString>>. Думаю, с ним проблем не будет.

Можно также посоветовать QReadWriteLock, если читать переменную будут несколько потоков, а запись производиться редко.
не знал о нём, спасибо, попробуемс
« Последнее редактирование: Май 13, 2010, 21:19 от serg_hd » Записан

kubuntu/Win7/x64/NetBeans
spectre71
Гость
« Ответ #17 : Май 14, 2010, 07:48 »

Речь идёт о QList<QPair<QString, QString>>. Думаю, с ним проблем не будет.

Читаем доку.

Цитировать
QList Class Reference
Note: All functions in this class are reentrant.

Цитировать
A thread-safe function can be called simultaneously from multiple threads, even when the invocations use shared data, because all references to the shared data are serialized.
A reentrant function can also be called simultaneously from multiple threads, but only if each invocation uses its own data.

Цитировать
By extension, a class is said to be reentrant if its member functions can be called safely from multiple threads, as long as each thread uses a different instance of the class. The class is thread-safe if its member functions can be called safely from multiple threads, even if all the threads use the same instance of the class.

Нет никакой гарантии что методы чтения данных QList потокобезопасны сейчас(что можно проверить посмотрев сорцы) или будут таковыми в следующих версиях. Так что защищать надо в любом случае.
Записан
Akon
Гость
« Ответ #18 : Октябрь 01, 2010, 11:24 »

Mutex нужен, т.к. присваивание это не атомарная операция

Присваивание будет неатомарным, если для него генерируется >1 машинной инструкции, исключая загрузку адресов. Например, для 32-разрядного типа на 16-разрядной платформе будет две машинные инструкции пересылки данных.

QAtomicInt нужен для несколько больших чем обычное присваивание действий. Непосредственно присваивание - это только часть атомарной операции.

По коду в топике - если sizeof(int) <= sizeof(machine_word) (т.е. 1 машинная инструкция на установку), то переменная должна быть volatile, синхронизация ни в каком виде не нужна.
« Последнее редактирование: Октябрь 01, 2010, 11:33 от Akon » Записан
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #19 : Октябрь 01, 2010, 12:58 »

я это спросил к тому - например мне в принципе не важно успеет прочитаться предыдущ значение переменной val до ее изменения или нет!!!
Довольно фантастическая ситуация (если "неважно"). Ну тогда чтение защищать не нужно (не будем притворяться что поддерживаем 16-бит платформы  Улыбающийся). А запись все равно надо.  

1. а если переменная VAL имеет тип QVariant или является какой нить структурой?

2. если я введу мьютекс, то на сколько примерно упадет скорость работы с этой переменной? как это можно оценить?

3. сколько вносят задержки сам вызов и выполнение функций getValue и setValue (примерно), ведь можно чтобы уменьшить время обработки - просто объявить эту переменную как Public (теоретически) Улыбающийся
В лучшем случае - доли процента. В худшем - раз в 10. Все зависит от того насколько интенсивна "конкуренция за ресурс". Если реально нужна скорость - выкидывайте мутексы и переходите на атомарные локи
Записан
Страниц: 1 [2]   Вверх
  Печать  
 
Перейти в:  


Страница сгенерирована за 0.166 секунд. Запросов: 22.