crossplatform.ru

Здравствуйте, гость ( Вход | Регистрация )


  Ответ в Синхронизация при сигналах и слотах в разных потоках
Введите ваше имя
Подтвердите код

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

Опции сообщения
 Включить смайлы?
Иконки сообщения
(Опционально)
                                
                                
  [ Без иконки ]
 


Последние 10 сообщений [ в обратном порядке ]
Авварон Дата 25.1.2013, 17:38
  Прикольно, даже не знал, что такие есть, всегда использовал toX() аналоги.
iReset Дата 25.1.2013, 12:38
  http://www.doc.crossplatform.ru/qt/4.7.x/qstring.html
Цитата
Note: All functions in this class are reentrant, except for ascii(), latin1(), utf8(), and local8Bit(), which are nonreentrant.

Алексей1153 Дата 25.1.2013, 11:28
  Авварон, он, наверное, имел в виду не QString, а юзерские классы
Авварон Дата 25.1.2013, 9:28
  Лень в доку лезть, а какие ф-ии у QString нереентрабельны?
iReset Дата 25.1.2013, 8:45
 
Цитата(Авварон @ 24.1.2013, 23:04) *
Всё там у QString нормально....
Да, точно, с изменением все нормально. Спасибо, развеял сомнения.
Тогда синхронизация нужна только при использовании нереентерабельных функций.
Авварон Дата 24.1.2013, 22:04
  iReset
Всё там у QString нормально. У шаред классов атомарно копирование - при передаче строки в поток мы получаем 2 копии с рефкаунтом 2.
При попытке изменить строку делается detach() - если счетчик ссылок больше 2х, то создается новая дата, туда копируется содержимое (заметь, это всё обращения на чтение), затем делается deref() оригиналу и только после этого идет изменение строки.
Самое плохое, что может случиться - это если 2 потока сделают детач() "одновременно" - тогда будет создано еще 2 копии, а исходник будет уничтожен при deref() той строки, что закончила detach() последней. Но эта ситуация достаточно маловероятна и чревата только падениями производительности.
Алексей1153 Дата 24.1.2013, 10:42
  с циклом - понятно, ок

Ну, видимо, класс потока сам и запустил петлю. Я сам явно не запускал
iReset Дата 24.1.2013, 10:40
 
Цитата(Алексей1153 @ 24.1.2013, 10:57) *
выходит, если указать Qt::QueuedConnection , то аргументы по значению можно передавать без синхронизации
а вот указатели на локальные данные при Qt::QueuedConnection точно нельзя по определению
Все можно передавать безопасно, только пользоваться с оглядкой :).

Цитата(Алексей1153 @ 24.1.2013, 10:57) *
так, а это что за комиссия )
Цитата
Qt::QueuedConnection 2
Слот вызывается когда элемент управления возвращает управление в цикл обработки событий в потоке получателя. Слот выполняется в потоке получателя.

Судя по оригиналу
Цитата
The slot is invoked when control returns to the event loop of the receiver's thread. The slot is executed in the receiver's thread.
тут неправильный перевод. Должно быть
Цитата
Слот вызывается, когда управление возвращается циклу обработки событий в потоке получателя. Слот выполняется в потоке получателя.


Цитата(Алексей1153 @ 24.1.2013, 10:57) *
у меня поток не использует контролы и цикл обработки событий. Или это неважно ?
Ну контролы фиг с ними, а как ты без цикла обработки событий хочешь получить сигнал? Если поток на основе QThread, то он сам запускает свой цикл обработки событий (тут, второй абзац).
Алексей1153 Дата 24.1.2013, 9:57
  выходит, если указать Qt::QueuedConnection , то аргументы по значению можно передавать без синхронизации

а вот указатели на локальные данные при Qt::QueuedConnection точно нельзя по определению

так, а это что за комиссия )
Цитата
Qt::QueuedConnection 2
Слот вызывается когда элемент управления возвращает управление в цикл обработки событий в потоке получателя. Слот выполняется в потоке получателя.


у меня поток не использует контролы и цикл обработки событий. Или это неважно ?
iReset Дата 24.1.2013, 9:40
 
Цитата(ssoft @ 24.1.2013, 10:01) *
1. Если передача параметров происходит по значению.
...
то при асинхронном вызове (через очередь сообщений), передаваемые данные копируются и синхронизировать ничего не нужно.

А вот для меня этот ответ не совсем полон и остаются вопросы. Поясню:
1. Все функции в классе QString реентерабельны, за исключением некоторых (тут в самом начале). Т.е. при вызове этих функций уже необходимо обеспечивать блокировки. Другие функции, вроде бы, можно использовать в разных потоках, потому что у нас две копии QString.
Но...
2. QString использует неявное разделение данных (тут 4 абзац). Т.е. обе копии QString будут указывать на одни и те же данные до их изменения.

Что будет при одновременном изменении строки в одном потоке и чтении в другом? Вероятно, каша, поскольку для хранения данных в QString используется структура
    struct Data {
        QBasicAtomicInt ref;
        int alloc, size;
        ushort *data;
        ushort clean : 1;
        ushort simpletext : 1;
        ushort righttoleft : 1;
        ushort asciiCache : 1;
        ushort capacity : 1;
        ushort reserved : 11;
        ushort array[1];
    };

и, естественно, она обновится не атомарно.

Все это мои теоретические выкладки, на практике не проверял.

Цитата(Алексей1153 @ 24.1.2013, 10:12) *
...я именно про случай без ссылок. Я в детали механизма сигналов/слотов глубоко не вникал - вероятно они уже имеют свои синхронизаторы для этого случая ? То есть - в некий "почтовый ящик" значение положилось, а потом его адресат (слот) вытащит, и неважно, что это из другого потока произошло

Я думаю, что если в документации (тут, после примера 3 абзац) прямо сказано, что соединяться можно с использованием соединения через очередь, то это работает.

Цитата(Алексей1153 @ 24.1.2013, 10:12) *
а со ссылками (неважно, кстати, константные или нет) - ну тут и так понятно, что синхронизировать надо

Если речь идёт про классы Qt, то не обязательно, если используются только потокобезопасные функции (тут).
Просмотр темы полностью (откроется в новом окне)
RSS Текстовая версия Сейчас: 29.4.2024, 3:25