QtConcurrent vs QThread

[ecspertiza]

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

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

[Kolobok]

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

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

[ecspertiza]

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

[Amigo_sa]

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

The QtConcurrent namespace provides high-level APIs that make it possible to write multi-threaded programs without using low-level threading primitives such as mutexes, read-write locks, wait conditions, or semaphores. Programs written with QtConcurrent automatically adjust the number of threads used according to the number of processor cores available. This means that applications written today will continue to scale when deployed on multi-core systems in the future.

[SASA]

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

[lit-uriy]

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

[Igors]

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

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

[fuCtor]

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

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

[SABROG]

и насколько я понимаю с ним нереально использовать всю силу сигнало\слотовой модели.

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

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

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

Код

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

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

[lit-uriy]

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

[Kolobok]

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

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

[fuCtor]

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

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

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

[lit-uriy]

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

Код

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

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

[Kolobok]

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

[lit-uriy]

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

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