This is my first experience on threading with Qt, so bear with me.
I have a singleton "system" object which periodically executes a heavy piece of code.
I control the system singleton from my UI, but the system is not aware of the UI.
I create a thread in my main, and then move the system to it:
QThread systemThread;
System::instance()->moveToThread(&systemThread);
systemThread.start();
qApp.exec();
The UI hangs until the system's periodical processing cycle is complete.
I have also tried to subclass QThread and calling exec from the run method.
What could be the problem? I'm certainly doing something wrong.
Best regards
See the excellent article about Threads, Events and QObjects in the Qt developer wiki. Something seems to be wrong with the thread affinity, you can check that with QObject::thread().
I advice you to follow this guideline from a Qt Developer himself when implementing multithreading: https://www.qt.io/blog/2010/06/17/youre-doing-it-wrong
It is way more effective and painless.
systemThread.start() will start systemThread.run() method in thread so you need to implement it inside run().
To create your own threads, subclass QThread and reimplement run().
Related
The SDL documentation for threading states:
NOTE: You should not expect to be able to create a window, render, or receive events on any thread other than the main one.
The glfw documentation for glfwCreateWindow states:
Thread safety: This function must only be called from the main thread.
I have read about issues regarding the glut library from people who have tried to run the windowing functions on a second thread.
I could go on with these examples, but I think you get the point I'm trying to make. A lot of cross-platform libraries don't allow you to create a window on a background thread.
Now, two of the libraries I mentioned are designed with OpenGL in mind, and I get that OpenGL is not designed for multithreading and you shouldn't do rendering on multiple threads. That's fine. The thing that I don't understand is why the rendering thread (the single thread that does all the rendering) has to be the main one of the application.
As far as I know, neither Windows nor Linux nor MacOS impose any restrictions on which threads can create windows. I do know that windows have affinity to the thread that creates them (only that thread can receive input for them, etc.); but still that thread does not need to be the main one.
So, I have three questions:
Why do these libraries impose such restrictions? Is it because there is some obscure operating system that mandates that all windows be created on the main thread, and so all operating systems have to pay the price? (Or did I get it wrong?)
Why do we have this imposition that you should not do UI on a background thread? What do threads have to do with windowing, anyways? Is it not a bad abstraction to tie your logic to a specific thread?
If this is what we have and can't get rid of it, how do I overcome this limitation? Do I make a ThreadManager class and yield the main thread to it so it can schedule what needs to be done in the main thread and what can be done in a background thread?
It would be amazing if someone could shed some light on this topic. All the advice I see thrown around is to just do input and UI both on the main thread. But that's just an arbitrary restriction if there isn't a technical reason why it isn't possible to do otherwise.
PS: Please note that I am looking for a cross platform solution. If it can't be found, I'll stick to doing UI on the main thread.
While I'm not quite up to date on the latest releases of MacOS/iOS, as of 2020 Apple UIKit and AppKit were not thread safe. Only one thread can safely change UI objects, and unless you go to a lot of trouble that's going to be the main thread. Even if you do go to all the trouble of closing the window manager connection etc etc you're still going to end up with one thread only doing UI. So the limitation still applies on at least one major system.
While it's possibly unsafe to directly modify the contents of a window from any other thread, you can do software rendering to an offscreen bitmap image from any thread you like, taking as long as you like. Then hand the finished image over to the main thread for rendering. (The possibly is why cross platform toolkits disallow/tell you not to. Sometimes it might work, but you can't say why, or even that it will keep working.)
With Vulkan and DirectX 12 (and I think but am not sure Metal) you can render from multiple threads. Woohoo! Of course now you have to figure out how to do all the coordination and locking and cross-synching without making the whole thing slower than single threaded, but at least you have the option to try.
Adding to the excellent answer by Matt, with Qt programs you can use invokeMethod and postEvent to have background threads update the UI safely.
It's highly unlikely that any of these frameworks actually care about which thread is the 'main thread', i.e., the one that called the entry point to your code. The real restriction is that you have to do all your UI work on the thread that initialized the framework, i.e., the one that called SDL_Init in your case. You will usually do this in your main thread. Why not?
Multithreaded code is difficult to write and difficult to understand, and in UI work, introducing multithreading makes it difficult to reason about when things happen. A UI is a very stateful thing, and when you're writing UI code, you usually need to have a very good idea about what has happened already and what will happen next -- those things are often undefined when multithreading is involved. Also, users are slow, so multithreading the UI is not really necessary for performance in normal cases. Because of all this, making a UI framework thread-safe isn't usually considered beneficial. (multithreading compute-intensive parts of your rendering pipeline is a different thing)
Single-threaded UI frameworks have a dispatcher of some sort that you can use to enqueue activities that should happen on the main thread when it next has time. In SDL, you use SDL_PushEvent for this. You can call that from any thread.
I am learning how to use PyQt5 and there are quite a few points that elude me.
I have started implementing QThreads to replace the threads I have been using in my UI as I realised that mixing threads and QThreads could possibly lead to issues later and have started using pyqtSignal simultaneously
So far I have seen that the pyqtSygnal needs to be implemented on a class level to be able to work ( putting it in a class constructor does not work )
In the architecture I use currently, I have a pyqtSignal that is instantiated in the main thread and is then used by all of the child threads. This is due to having one class that is responsible for my logs of all the program.
I am unsure if this is a good implementation or not.
Here are my questions :
are pyqtSignals thread safe ?I know that they use a queue system to be thread safe but is the emit() method itself thread safe ? My understanding of them is a bit limited
Do I need to protect my pyqtSignals with locks ?
Can I have multiple different signals emitting to the same slot without having any issues ?
The signals are one of the few elements of the QObjects that are thread-safe so it is not necessary to protect the data. So you can have different types of signals connected to the same slot.
Since the signals are thread-safe then Qt recommended to communicate QObjects that live in different threads.
I use Qt and C++. I have a list of threads (Qlist<QtThread>).
I try to synchronize them. All threads calculate some values. And I want to take them.
Have you any ideas? thank a lot
You can use the finished() signal of a thread to execute a slot when your thread finishes executing.
Your question is a bit broad, but Qt has a lot of documentation on different thread synchronization methods.
The base of the docs is at Threading Support in Qt. The specific part you should find the info in is the Synchronizing Threads section. It lists the various mutex, locks, semaphores, wait conditions that are available in the Qt framework.
The documentation for all these classes has example usage code. Also have a look at the Threading and Concurrent Programming Examples, you'll probably find what you're after in there.
I have Qt4 app which binds QStandardItemModel to the QListView and have the model updated from background/non-UI thread.
Sometimes, when the QStandardItem's setText(..) method is called very repeatedly from the non-UI thread, the application will crash at a la dataChanged(..) handler. I can reproduce the issue by calling setText("xxxxx") repeatedly in a for loop. In my app, the data is read from network hence I update the model in separate, non-UI thread.
Is this a common pb? If I understand correctly, this is related to queued connection and QStandardItemModel is not thread safe? How to get around this issue?
Thanks!
QStandardItemModel is part of the QtGui Library, iirc all classes in there are considered not threadsafe. You should be ok if you move the actual setting of the data into the GUI thread. You can do that pretty easily by using a queued signal from you network thread.
Main (function main is there) thread of my program is reserved for non-GUI tasks. It calls a number of lengthy calculation functions. All implemented GUI's have been doing their work in a separate threads.
I'm now going to implement one more GUI using Qt. Qt documentation says all GUI related tasks should be done in main thread.
In my case, inserting occasional QCoreApplication::processEvents() calls in main thread would be virtually useless due to great delays between them.
Is there any way to overcome this constraint of Qt?
Is it impossible to do something non-GUI related in main thread of Qt program?
No, you should be doing your calculations in a separate thread. As you already mentioned, there is a work-around available in QCoreApplication::processEvents(), but it sounds like you're unable to make that work for you.
If you don't want to have to do all the work of setting up a QThread and moving all your code, you may find that the QtConcurrent::run function is useful - it allows you to run a function asynchronously.
A few pointers: You should try and keep your main (GUI) thread as light as possible. Large amounts of IO or calculations should either be done asynchronously using QtConcurrent::run, or run inside a separate QThread. Depending on the complexity of your code, you may be able to get away with the QtConcurrent method.
It's best to offload the long computations onto other threads so the main GUI thread remains responsive. The old-school uniprocessing way of doing things would be be to make sure your computations never run for too long without polling GUI event handler, but that doesn't scale to multi-cores.
Fortunately Qt has excellent threading support. In the past you'd have to roll-you-own system for e.g farming out tasks to a thread-pool using QThread, QMutex, QWaitCondition etc, but recent Qt releases have made things easier with higher level abstractions like QThreadPool, QtConcurrent::run and QFuture.
I don't know how things will go if you call QApplication::exec() from another thread, which then becomes your gui thread. Just an idea.
(Let us know if it works, it'd be interesting...)
The concept of main thread is not clearly defined in Qt documentation. Actually, the main thread of a process (process that executes the Process.run function) can be different from the main Qt thread (thread that instantiates the first Qt object like a QApplication), although both "main" threads are often the same one.
Example of valid code structure:
function below will run in the process' non-main thread 'thread-1', that will become immediately Qt's main thread.
def startThread1():
app = QApplication(sys.argv)
app.exec_() # enter event loop
code below run in process' main thread, not to be confused with the main Qt and unique GUI thread of the process.
thread1 = Thread(target=self.startThread1)
thread1.start()
input('I am busy until you press enter')