Развить пример

[Igors]

Добрый день

В соседней теме рассматривается этот пример http://doc.qt.io/qt-5/qthread.html#details, в котором предлагается цивильный способ "выноса операции в поток". Впрочем и простецкое наследование от QThread не осуждается, идет следующим примером. Обсуждение получилось довольно "академическое", типа "а чего это сигнал public, это же небезопасно!". Тут хотелось бы поговорить о другом

Да, так мы умеем "выносить", но что если "выносимых" две или больше или вообще они идут мутным потоком? Их можно свалить одному контроллеру, но так (в среднем) задействуется лишь одно ядро, операции будут ждать. Плодить контроллеры явно не хочется, а QtConcurrent не в масть. Что бы Вы предложили?

Спасибо

[_OLEGator_]

Использовать QThreadPool.

[Авварон]

Допустим, у нас задачи сыпятся в общую очередь. Тогда.
I. Как раз таки конкурент в масть. Контроллер обрабатывает новую задачу, создаёт футуру, вешает на неё вотчера. Вотчеров можно создать заранее (по кол-ву тредов) и сделать очередь футур, к-ую разгребают свободные вотчеры. Это если не хочется аллоцировать вотчеров.
II. Несколько тредов, к-ые крутят эвентлуп, в каждом живёт воркер. Все воркеры подсоединены к сигналу контроллера естьРабота(). При появлении задачи мы просто кладем ее в очередь, эмитим сигнал. Первый свободный вотчер "успеет" схватить задачу, остальные сработают вхолостую. По сути тоже, что I, только вместо спящих на QWaitCondition тредах в пуле мы крутим всегда эвентлупы (и спим на select'е).

[rudireg]

Добрый день

В соседней теме рассматривается этот пример http://doc.qt.io/qt-5/qthread.html#details, в котором предлагается цивильный способ "выноса операции в поток". Впрочем и простецкое наследование от QThread не осуждается, идет следующим примером. Обсуждение получилось довольно "академическое", типа "а чего это сигнал public, это же небезопасно!". Тут хотелось бы поговорить о другом

Да, так мы умеем "выносить", но что если "выносимых" две или больше или вообще они идут мутным потоком? Их можно свалить одному контроллеру, но так (в среднем) задействуется лишь одно ядро, операции будут ждать. Плодить контроллеры явно не хочется, а QtConcurrent не в масть. Что бы Вы предложили?

Спасибо

А почему

задействуется лишь одно ядро

-  если мы сделаем moveToThread ? Разве слоты перенесенного QObject в подобном случае не должны выполнятся в другой нитке?

[lit-uriy]

rudireg, отдельный поток не гарантирует отдельное ядро процессора

[rudireg]

rudireg, отдельный поток не гарантирует отдельное ядро процессора

А можно ли средствами QT назначать нитки разным ядрам?
Я всегда думал что ОС берет на себя функции распределения.

[Igors]

А можно ли средствами QT назначать нитки разным ядрам?

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

Я всегда думал что ОС берет на себя функции распределения.

Да, берет, Напр 2 нитки считают - ОС автоматом будет им выделять кванты времени на тех ядрах что сочтет нужным. Если в это время активны еще приложения - им тоже выделится время. Но "кормить" нитки (т.е. давать им задачи и пускать на выполнение) - забота не ОС, а программиста