Russian Qt Forum

Прошу объяснения так сказать на пальцах, в чем разница ???

Плюсы, минусы, я пока особой разницы не вижу, ну только кроме разных вызовов и использования.

QtConcurrent
Скорость написания кода выше. Меньшее количество классов/файлов.

QThread
Большая гибкость.

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

Ассистант утверждает, что Concurrent - для упрощения работы и унификации.

У QtConcurrent есть механизм паралельных вычислений.

В моём понимании QtConcurrent нужен для однообразной обработки над контейнерами данных, когда эта обработка имеет непринципиальное для всей программы значение. В QtConcurrent нет возможности регулировать приоритет выполнения потока. И, как я заметил, при наличии большой работы над каждым элементом контейнера. Приложение начинает жутко тормозить. В таких случаях лучше использовать QThread и задавать пониженный приоритет

Также скорость QtConcurrent заметно падает если одни из задач массива требуют значительно больше времени чем другие. Это еще называется "гранулярностью".

Не обязательно над контейнерами. Тот же run, удобен когда необходимо запустить некий участок кода в отдельный поток (в фон), чтобы  не блокировать выполенение основного потока, НО при этом использование QThread было бы избыточным. Например процесс печати, заводить специализированный поток не вижу смысла, т.к. задача может быть не профильная, а использовать поток из пула вполне.

Достаточно унаследоваться от QObject'a и передать адрес на метод твоего класса вместо адреса обычной Си функции. Я именно так реализовал работу сигналов и слотов в своем потоке, который запускал через QtConcurrent::run().


QThread::currentThread() статический метод, который используется в нескольких Qtшных примерах для демонстрации возможностей QtConcurrent, поэтому такое должно работать:

C++ (Qt)
QThread::currentThread()->setPriority(QThread::LowestPriority);
 

Судя по исходникам QThread - currentThread() динамически вызывает API GetCurrentThread() под Win32. И метод setPriority() вызывает SetThreadPriority(). По логике всё должно работать.

в том-то и дело, что currentThread, а это основной поток, его как раз и не надо трогать

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

Потомучто потоки для выполнения берутся из пула. Следовательно этот же поток потом может достаться другой задаче, либо если будет идти выполнение mapreduce|filter то одни элименты будут обрабатываться с иным приоритетом, который когда то по необходимости выставил программист. Поэтому при таком финте нужно не забыть вернуть приоритет по окончании выполнения.

>Нет, это не так.
Что значит не так?
Вот код:

C++ (Qt)
//...
QThread::currentThread()->setPriority(QThread::LowestPriority);
//...
 

текущий поток, в котором приведён этот код, будет подвергнут изменению приоритета

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

>QtConcurrent выполняет этот код
он вообще к этому коду отношения не имеет.

Но теперь я понял что имел в виду SABROG. Он имел в виду - воткнуть эту строку в функцию, которая передаётся в QtConcurrent.

Разве это проблема? Перед запуском выставить приоритет, после окончания восстановить. А сейчас получается, что нужно этот код выполнять столько раз, сколько элементов в контейнере.

Было бы тогда логичней выставлять приоритет ВСЕМУ пулу потоков, а не одному из него. Но все равно как то криво выходит.

PS разве смена приоритета будет сильно просаживать? но тупо выглядеть будет факт.