update() called from different threads, want paintEvent() to run different code depending on update() arguments
-
Hi there,
I am new to programming, C++ and very new to Qt.
I am writing a multithreaded program and am having program crashes at runtime. Usually before the program crashes I am given the error "*** glibc detected *** ./blah: double free or corruption (fasttop). I believe this is because I am using a multithreaded program, and am using the update() function on the main program window from both threads, and as the threads are running as fast as possible, the update() function may be called at the same time and both threads will be trying to access the same data in the paintEvent.
I think this is fixable (in some way or another) because I am calling update() with different arguments to specify the region I want updated (there are 2 pixmaps that get painted on the same window widget next to each other). i.e in the GUI thread I am calling update(10, 10, 780, 610) and in the other thread I am calling update (810, 10, 780, 610). Do arguments to update() get passed to the PaintEvent? If so I could check what the x-coordinate argument in the update() command is from within the paint event and then use an if statement to check whether the x-coordinate corresponds to the left or right pixmap and execute their respective painting code.
This may not be the way the update() function works, and if so, could anyone suggest a better solution?
Any help would be greatly appreciated.
Thanks.
-
Never modify UI from other threads than main thread (where the UI is living)! Qt GUI is NOT thread safe!
You can emit signals from your threads and connect slots to them in the main thread where you can modify the UI. -
Never modify UI from other threads than main thread (where the UI is living)! Qt GUI is NOT thread safe!
You can emit signals from your threads and connect slots to them in the main thread where you can modify the UI.@jsulm Thanks for your reply. I am new to signals and slots so would have to find out how they work and how to implement the signal in the pthread. What would the slot in the Window class be? Would it just be a function which calls update(x, y, w, h)? Is the update() function able to be used as a slot directly?
EDIT: Also I am accessing variables from another thread. The thread is created with a pointer to the instance of the Window class and I am using variables like this: window->a;
I assume this is also bad, can this be solved with signals and slots also?Thanks again.
-
Hi and welcome to devnet,
Take look at the Signals & Slots documentation. It should help you get started.
-
@jsulm Thanks for your reply. I am new to signals and slots so would have to find out how they work and how to implement the signal in the pthread. What would the slot in the Window class be? Would it just be a function which calls update(x, y, w, h)? Is the update() function able to be used as a slot directly?
EDIT: Also I am accessing variables from another thread. The thread is created with a pointer to the instance of the Window class and I am using variables like this: window->a;
I assume this is also bad, can this be solved with signals and slots also?Thanks again.
@StuckInALoop Regarding accessing variables from other classes: it depends on how you access them. Do you write them? If it is only read access then you do not have to serialize the access. If you read/write then you have to make sure that you do not get race conditions.
In general it is not a good idea to access those main window parts from other threads directly. It would be better to pass all needed data on thread initialization or via signals/slots.
-
Never modify UI from other threads than main thread (where the UI is living)! Qt GUI is NOT thread safe!
You can emit signals from your threads and connect slots to them in the main thread where you can modify the UI.Do arguments to update() get passed to the PaintEvent?
Yes they do, but the events might get compressed - the paint event will be called with a region that's a union of all the
updatecalls' regions (that were placed before the paint event).I am writing a multithreaded program and am having program crashes at runtime. Usually before the program crashes I am given the error "*** glibc detected *** ./blah: double free or corruption (fasttop). I believe this is because I am using a multithreaded program, and am using the update() function on the main program window from both threads, and as the threads are running as fast as possible, the update() function may be called at the same time and both threads will be trying to access the same data in the paintEvent.
Yes, you most probably have a race condition.
Thanks for your reply. I am new to signals and slots so would have to find out how they work and how to implement the signal in the pthread.
You can't have signals in a
pthread, Qt signals and slots are bound to Qt, so you should useQThreadinstead.What would the slot in the Window class be? Would it just be a function which calls update(x, y, w, h)?
It would.
Is the update() function able to be used as a slot directly?
Depends on the syntax used (Qt 4 or Qt 5).
But assume the answer is: Yes, but only the overload that doesn't take any arguments.I assume this is also bad, can this be solved with signals and slots also?
It is (most of the time) and it can if your Window class derives from
QObject, if it doesn't then you can't use signal and slots. Your variables can be read from any thread (as @jsulm duly noted), however you must ensure that no thread will modify them in the meantime (which you can't if the base class isQWidgetand the variables belong to that base).@jsulm said:
Qt GUI is NOT thread safe!
Sadly, it's not even reentrant ... :|
