|
Название: Развить пример Отправлено: Igors от Июнь 07, 2016, 10:43 Добрый день
В соседней теме рассматривается этот пример http://doc.qt.io/qt-5/qthread.html#details (http://doc.qt.io/qt-5/qthread.html#details), в котором предлагается цивильный способ "выноса операции в поток". Впрочем и простецкое наследование от QThread не осуждается, идет следующим примером. Обсуждение получилось довольно "академическое", типа "а чего это сигнал public, это же небезопасно!". Тут хотелось бы поговорить о другом Да, так мы умеем "выносить", но что если "выносимых" две или больше или вообще они идут мутным потоком? Их можно свалить одному контроллеру, но так (в среднем) задействуется лишь одно ядро, операции будут ждать. Плодить контроллеры явно не хочется, а QtConcurrent не в масть. Что бы Вы предложили? Спасибо Название: Re: Развить пример Отправлено: _OLEGator_ от Июнь 07, 2016, 11:03 Использовать QThreadPool.
Название: Re: Развить пример Отправлено: Авварон от Июнь 08, 2016, 14:45 Допустим, у нас задачи сыпятся в общую очередь. Тогда.
I. Как раз таки конкурент в масть. Контроллер обрабатывает новую задачу, создаёт футуру, вешает на неё вотчера. Вотчеров можно создать заранее (по кол-ву тредов) и сделать очередь футур, к-ую разгребают свободные вотчеры. Это если не хочется аллоцировать вотчеров. II. Несколько тредов, к-ые крутят эвентлуп, в каждом живёт воркер. Все воркеры подсоединены к сигналу контроллера естьРабота(). При появлении задачи мы просто кладем ее в очередь, эмитим сигнал. Первый свободный вотчер "успеет" схватить задачу, остальные сработают вхолостую. По сути тоже, что I, только вместо спящих на QWaitCondition тредах в пуле мы крутим всегда эвентлупы (и спим на select'е). Название: Re: Развить пример Отправлено: rudireg от Ноябрь 02, 2016, 20:46 Добрый день В соседней теме рассматривается этот пример http://doc.qt.io/qt-5/qthread.html#details (http://doc.qt.io/qt-5/qthread.html#details), в котором предлагается цивильный способ "выноса операции в поток". Впрочем и простецкое наследование от QThread не осуждается, идет следующим примером. Обсуждение получилось довольно "академическое", типа "а чего это сигнал public, это же небезопасно!". Тут хотелось бы поговорить о другом Да, так мы умеем "выносить", но что если "выносимых" две или больше или вообще они идут мутным потоком? Их можно свалить одному контроллеру, но так (в среднем) задействуется лишь одно ядро, операции будут ждать. Плодить контроллеры явно не хочется, а QtConcurrent не в масть. Что бы Вы предложили? Спасибо А почему Цитировать задействуется лишь одно ядро - если мы сделаем moveToThread ? Разве слоты перенесенного QObject в подобном случае не должны выполнятся в другой нитке?Название: Re: Развить пример Отправлено: lit-uriy от Ноябрь 03, 2016, 06:21 rudireg, отдельный поток не гарантирует отдельное ядро процессора
Название: Re: Развить пример Отправлено: rudireg от Ноябрь 03, 2016, 08:52 rudireg, отдельный поток не гарантирует отдельное ядро процессора А можно ли средствами QT назначать нитки разным ядрам?Я всегда думал что ОС берет на себя функции распределения. Название: Re: Развить пример Отправлено: Igors от Ноябрь 03, 2016, 09:15 А можно ли средствами QT назначать нитки разным ядрам? Нет, такая фишка есть у интела и то не для всех платформ.Я всегда думал что ОС берет на себя функции распределения. Да, берет, Напр 2 нитки считают - ОС автоматом будет им выделять кванты времени на тех ядрах что сочтет нужным. Если в это время активны еще приложения - им тоже выделится время. Но "кормить" нитки (т.е. давать им задачи и пускать на выполнение) - забота не ОС, а программиста |