Очереди, самодельные сигналы

[galilley]

Самый простой способ: запустить нитку, она начнет крутить  свой eventLoop. Когда для нитки есть работа - послать ей сигнал. Нитка выполнит задание, вернет результаты (также через сигнал) и опять уйдет в eventLoop. Для этого в Qt все заточено, дополнительные семафоры не нужны. Просто создавайте и связывайте слоты/сигналы

Это всё понятно, но мне как раз нужда была синхронность, чтобы я мог, например, послать задание во вторичный поток, потом ещё что-нить сделать по ходу в первичном, потом дождаться ответа и выполнять программу дальше.

[Авварон]

это асинхронность...

[Igors]

Но насколько я понял event loop всегда относится к главному потоку и в Qthread не поддерживается.
Или я ошибаюсь?

Ошибаетесь. Метод exec() (он стоит в run() по умолчанию) запускает eventLoop этой нитки

[Igors]

Это всё понятно, но мне как раз нужда была синхронность, чтобы я мог, например, послать задание во вторичный поток, потом ещё что-нить сделать по ходу в первичном, потом дождаться ответа и выполнять программу дальше.

А Вас никто не заставляет ждать пока задание выполнится. Делайте коннект QueuedConnection и управление вернется после того как задание помещено в очередь нитки. А хотите ждать - используйте BlockingQueuedConnection

[labview]

Но насколько я понял event loop всегда относится к главному потоку и в Qthread не поддерживается.
Или я ошибаюсь?

Ошибаетесь. Метод exec() (он стоит в run() по умолчанию) запускает eventLoop этой нитки

Да, я попутал, где то прочитал, что в Qt за User Interface всегда отвечает Main, и спутал это с за Event Loop всегда отвечает Main.
То есть в нитях нельзя создавать свои пользовательские окна.

Да, я согласен с тем, что система сигналов и слотов реализована достаточно хорошо. Но мне бы хотелось иметь прямой доступ к Thread, а не через его Event Loop, понимаете?
Ещё мне бы хотелось, раз уж такой возможности нет?!, сбрасывать сигналы (то есть делать их недействительными), если нить их например не может обработать. А так же иметь возможность указать максимальное количество сигналов (размер буфера) для Event Loop определённой нити. И ещё менять сигналы местами или добавлять сигналы не в конец буфера, а в начало например.

Блин, во время написания этого ответа вспомнился момент из камеди клаба:
http://video.google.com/videoplay?docid=4145626155888365960#

[galilley]

А Вас никто не заставляет ждать пока задание выполнится. Делайте коннект QueuedConnection и управление вернется после того как задание помещено в очередь нитки. А хотите ждать - используйте BlockingQueuedConnection

Но я хотел бы ещё ту же получить ответ из вторичного треда.. хотя да, ответ можно спросить и напрямую, дождавшись пока отработает BlockingQueuedConnection. Надо подумать над этим, спасибо

Да, я согласен с тем, что система сигналов и слотов реализована достаточно хорошо. Но мне бы хотелось иметь прямой доступ к Thread, а не через его Event Loop, понимаете?
Ещё мне бы хотелось, раз уж такой возможности нет?!, сбрасывать сигналы (то есть делать их недействительными), если нить их например не может обработать. А так же иметь возможность указать максимальное количество сигналов (размер буфера) для Event Loop определённой нити. И ещё менять сигналы местами или добавлять сигналы не в конец буфера, а в начало например.

А что за задача, если не секрет? Может там надо решать проблему другими способами, или с другого угла.. да и крайне интересны условия, в которых могли возникнуть такие потребности.

[Igors]

Но я хотел бы ещё ту же получить ответ из вторичного треда.. хотя да, ответ можно спросить и напрямую, дождавшись пока отработает BlockingQueuedConnection.

Случай когда надо ждать ответа - довольно редкий. В большинстве случаев ответ посылается из нитки выполнившей задание (тоже сигналом) и принимается в eventLoop главной (или др) нитки.  Др. словами гораздо удобнее "ждать с пользой" в eventLoop

[BRE]

IMHO стоит взглянуть на QRunnable + QThreadPool.
eventloop в простаивающей нитке все равно кушает процессор и чем больше таких ниток, тем больше кушает.

[labview]

А что за задача, если не секрет? Может там надо решать проблему другими способами, или с другого угла.. да и крайне интересны условия, в которых могли возникнуть такие потребности.

Ну во первых я не очень понимаю зачем каждой нити свой Event Loop, то есть каждая нить состоит из двух потоков - Event Loop + сам цикл нити. Наверняка как то можно передавать данные напрямую и синхронно в цикл нити, не используя Event Loop.

Во вторых нить например должна отправлять данные какому нибудь внешнему прибору. Допустим данные имеют разный приоритет. Для примера команда exit имеет высший приоритет, а если в данный момент в буфере Event Loop уже находятся другие команды низкого приоритета, то мне бы хотелось убрать команды низкого приоритета из буфера сигналов и сразу выполнить сигнал высокого приоритета. Ну или просто всунуть команду высокого приоритета в буфер на первое место, а остальные подождут.

Ну примерно понятно?

[BRE]

Сделать свою очередь заданий будет самое то.
Кстати на форуме были темы, где выкладывались готовые рабочие примеры организации таких задач.
Так же можно посмотреть реализацию QRunnable и QThreadPool.

[Igors]

Да, я согласен с тем, что система сигналов и слотов реализована достаточно хорошо. Но мне бы хотелось иметь прямой доступ к Thread, а не через его Event Loop, понимаете?

Думаю что понимаю Но, судя по тому что Вы рассказали, никакой необходимости в этом не видно

Ещё мне бы хотелось, раз уж такой возможности нет?!, сбрасывать сигналы (то есть делать их недействительными), если нить их например не может обработать. А так же иметь возможность указать максимальное количество сигналов (размер буфера) для Event Loop определённой нити. И ещё менять сигналы местами или добавлять сигналы не в конец буфера, а в начало например.

Мне кажется Вы путаете синхронное с асинхронным   Сигнал всего лишь "посылает нитке задание". На посылающей стороне как правило нет выбора - задачи посылаются исполняющей нитке в порядке их поступления. Но исполнитель совсем не обязан следовать тому же порядку. В любой момент он может вызвать processEvents и посмотреть какие еще задачи пришли, прервать выполнение текущей задачи, установить свой порядок выполнения задач и.т.п.

[Igors]

eventloop в простаивающей нитке все равно кушает процессор и чем больше таких ниток, тем больше кушает.

Вряд ли. Запускаем любую Qt программу которая открывает UI и ждет ввода пользователя (т.е. стоит на eventLoop). Активность процессора (ов) на нуле.

[BRE]

Вряд ли. Запускаем любую Qt программу которая открывает UI и ждет ввода пользователя (т.е. стоит на eventLoop). Активность процессора (ов) на нуле.

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

[Igors]

Ну во первых я не очень понимаю зачем каждой нити свой Event Loop, то есть каждая нить состоит из двух потоков - Event Loop + сам цикл нити. Наверняка как то можно передавать данные напрямую и синхронно в цикл нити, не используя Event Loop.

Когда ОС запускает нитку, дается ф-ция которую эта нитка начнет выполнять. Как только ф-ция вернет управление - нитка завершена. Qt по умолчанию запускает eventLoop. Вы можете вместо этого сделать свой цикл нитки (обычно не очень удобно), можете войти в eventLoop, выйти, опять войти - как угодно но все в пределах run() нитки.

Стандартная проблема с собственным циклом - нитке нужно ждать пока данных для обработки нет и нужно как-то сниматься с ожидания когда данные пришли. Во многих случаях выходит то же самое что делает eventLoop

[BRE]

Стандартная проблема с собственным циклом - нитке нужно ждать пока данных для обработки нет и нужно как-то сниматься с ожидания когда данные пришли. Во многих случаях выходит то же самое что делает eventLoop

А в чем эта проблема?
Нитка останавливается на объекте QWaitCondition::wait, когда задание добавляется, то делаем QWaitCondition::wakeOne и одна из ниток просыпается и подхватывает задание.