QtConcurrent vs QThreadPool vs QThread. Which to use?
-
Hello!
The global idea is to keep object in the thread and provide slots to QML. Which is better to use QtConcurrent or QThreadPool or QThread? Is there any inbox solution for it in QT?
I need something like this:
@bogong said in QtConcurrent vs QThreadPool vs QThread. Which to use?:
The global idea is to keep object in the thread and provide slots to QML. Which is better to use QtConcurrent or QThreadPool or QThread? Is there any inbox solution for it in QT?
I don't understand your problem.
Why not simply useQ_PROPERTY?It is an old maxim of mine that when you have excluded the impossible, whatever remains, however improbable, must be the truth. (Sherlock Holmes)
-
@bogong said in QtConcurrent vs QThreadPool vs QThread. Which to use?:
The global idea is to keep object in the thread and provide slots to QML. Which is better to use QtConcurrent or QThreadPool or QThread? Is there any inbox solution for it in QT?
I don't understand your problem.
Why not simply useQ_PROPERTY?@KroMignon said in QtConcurrent vs QThreadPool vs QThread. Which to use?:
Why not simply use Q_PROPERTY?
Qt Quick will invoke the methods to read/write the property directly (i.e. from the GUI thread) so it would be a race condition if the objects lived on a different thread unless, of course, you manually mutex the getters/setters on the C++ side
"La mort n'est rien, mais vivre vaincu et sans gloire, c'est mourir tous les jours"
~Napoleon BonaparteOn a crusade to banish setIndexWidget() from the holy land of Qt
-
@KroMignon said in QtConcurrent vs QThreadPool vs QThread. Which to use?:
Why not simply use Q_PROPERTY?
Qt Quick will invoke the methods to read/write the property directly (i.e. from the GUI thread) so it would be a race condition if the objects lived on a different thread unless, of course, you manually mutex the getters/setters on the C++ side
@VRonin said in QtConcurrent vs QThreadPool vs QThread. Which to use?:
Qt Quick will invoke the methods to read/write the property directly (i.e. from the GUI thread) so it would be a race condition
Yes, but that is up to the developper to handle this, you will always have to use mutex/atomics if you want to use multi-threading.
QtConcurrent/QThreadPool/QThread will not solve this!The easiest way, IMHO, is to use
Q_PROPERTYwithsignalsto propagate the changes. -
Hello!
The global idea is to keep object in the thread and provide slots to QML. Which is better to use QtConcurrent or QThreadPool or QThread? Is there any inbox solution for it in QT?
I need something like this: -
I believe that all three possibilities have different use cases. QtConcurrent and QThreadPool are more task-based whereas QThread is, well, a thread.
QtConcurrent provides easy access to put single functions into a multithreaded environment. I think it even uses a thread pool in the background. QtConcurrent is especially helpful in the context of the map and reduce operations. With QtConcurrent::run() the idea is just asynchronous execution. If you have short tasks you can use QtConcurrent.
The QThreadPool has two advantages over plain old threads: First, you don't have the thread creation cost if you spawn many short lived threads. And second, it helps avoiding oversubscription of CPU cores. In that sense its use is similar to QtConcurrent::run(): it is best utilized for short lived tasks.
If you want to a have a thread permanently running, QThread is your only reasonable choice. My preference is to use the default implementation of a thread and have it run the event queue. Then, I can use QMetaObject::invokeMethod with the thread as its first parameter to queue some work into that thread.
That all said: You should think twice if you really want to go down this route. First of all, it is a hassle to manage the GUI correctly from a separate thread as all GUI calls need to be inside the GUI thread. If you don't have a performance problem with your software, don't use additional threads. It has a non-negligible performance overhead. This is fact might introduce performance problems on its own. Furthermore, multithreading is prone to additional errors and bugs. This last argument is why you should avoid threads if they are not necessary for your performance.
