0

Is it safe to call widget's signal function from multiple threads simultaneously? Will Qt use some kind of internal mutex to provide security of its own data structures when multiple threads call some widget's signal simultaneously?

As i understand, it is safe and N simultaneous calls of a signal function will lead to N sequential calls of a connected signal.

Am i correct?

P.S. The threads that call a signal function are created with boost. I think, this is not important for this question. I cannot use another threads, because that threads are not related to GUI only, but they serve many parts of a program.

pavelkolodin
  • 2,859
  • 3
  • 31
  • 74

3 Answers3

1

To be concise about this, you don't call a signal, you emit a signal. Then Qt internally handles the firing of any slots that the signal is connected to.

Emitting a signal and having it firing slot(s) may or may not be thread safe depending on the connection type.

Read here for more information.

And I think that the thread being created by boost will be a problem - the signal/slot mechanism relies on the infrastructure of QThread and QObject. It may be better and simpler if you can use QThread rather than a boost thread.

docsteer
  • 2,506
  • 16
  • 16
  • 1
    "emit" it simple macro which replaced by nothing. So "emit" == "call". – PSyton Aug 28 '13 at 04:29
  • The link that you gave says that default connection type behaves like "Queued Connection" in case of signal is emitted from different thread than the thread the receiving object has affinity to (belongs to). So, it seems i don't have to think about this. – pavelkolodin Aug 28 '13 at 18:48
0

If you would be using QThreads, there would be no problem at all, as Qt manages such a situation automatically. So you (possible) problem arises from using boost threads.

However, there is a simple solution: make sure you connect the signals and slots using Qt::QueuedConnection. This will post an event into the Widget's thread's event loop and execute the slot in that thread. (this is what using QThreads does automatically when objects live in different threads).

Note that slot execution will be asynchronous in that case. If you need synchronous execution of slots (i.e. all slots must be finished before the code emitting the signal continues), use Qt::BlockingQueuedConnection

king_nak
  • 11,313
  • 33
  • 58
0

It depends on the connection. If the connection is direct, the emitting thread will be used to deliver the signal to connected slot. Is this safe? That depends on the slot. In particular, slots on QWidget cannot handle this. If the connection is queued, the signal is stored. The receiver object has an associated QThread, that thread has an event loop, and that event loop will deliver the stored signal to the receiver.

Your question describes the behavior of a queued connection. That's a valid possibility. The Qt event loop is thread safe. Both delivering signals to it, and calling slots from it are properly protected. Since there's only one QThread per receiver, that means queued signals are delivered sequentially.

MSalters
  • 173,980
  • 10
  • 155
  • 350
  • This page http://qt-project.org/doc/qt-4.8/threads-qobject.html#signals-and-slots-across-threads says that default connection type behaves like "Queued Connection" in case of signal is emitted from different thread than the thread the receiving object has affinity to (belongs to). – pavelkolodin Aug 28 '13 at 18:47