0

I have a simulation running on a std::thread that has regular sleeping periods and at the end of each period QWidget::update() is called on my custom QGraphicsObject. It works most of the time, sometimes calculating 100k iterations on a 1024^2 grid, but sometimes from a point QGraphicsView doesn't update itself anymore. I suspect some multi-threaded communication problem.

I've read that Cocos2d-x for example can't handle concurrent calls in it's API excluding some property modification. I haven't found information about thread safety on Qt docs, some people here said Qt Widgets are not thread-safe. Actually QWidget::update() is a public slot, so shall I try converting all direct function calls to update() to emit signals? I would like to do my threading in pure c++, what are constraints of this when working with Qt?

(I'll open a new question specifically about the problem if using std::thread like this is supposed to be safe)

MatrixAndrew
  • 265
  • 3
  • 13
  • Hardest part of creating questions is to find possible duplicates :( That question was put up 4 years ago and has 5383 views. I still couldn't find it on google after querying for "qt thread-safety" even though it had "qt" and "thread-safety" in its tags... Hmm – MatrixAndrew Sep 29 '15 at 13:36

1 Answers1

1

In Qt it is very important that methods of GUI objects are only called in the GUI (typically main) thread.

Signals and slots in Qt however do work over thread boundaries as long as the receiver thread (slot) is running an event loop (as the Qt thread obviously does). There is no other requirement on this thread or the signaller's thread. If you send a signal from a different thread, Qt automatically enqueues it into the receiver thread's event queue.

This can also be made explicit when setting up the signal/slot connection by passing the right connection type parameter. See the explanation of connection types in Qt doc.

So the answer is yes, you cannot reliably call any widget methods from other threads and yes, the signal/slots mechanism is a proper means of ensuring thread-safety when triggering GUI actions from a worker thread.

ypnos
  • 50,202
  • 14
  • 95
  • 141
  • 1
    Yes it works like a charm: signals: void scheduleUpdate(); //////////////// public: void requestUpdate() { emit scheduleUpdate(); } //////////////// public slots: void executeUpdate() { update(); } By calling scheduleUpdate from std::thread it gives the execution to a the QObject's thread this way. – MatrixAndrew Sep 29 '15 at 16:15