Emitting and Running Slots

Question

One thread does emit signal1();

The second thread does emit signal2(); after the first thread sent its signal (there is the same mutex blocked before releasing a call to both threads, and I registered it, I see in my log that the first thread gets a lock before the second thread)

first thread and second thread, not GUI thread.

Are there any guarantees that the signal1 slot will be called before the signal2 slot?

Answer 1

Since emitter and receiver objects work in different threads, slots will not be executed synchronously: Qt uses the default connection by default instead of direct connection. However, you can force synchronous execution using a connection with a queue lock (see also http://qt-project.org/doc/qt-4.8/qt.html#ConnectionType-enum for a description of the different types of connections ) when connecting signals and slots.

But connecting to a queue lock has a cost: the emitter flow is blocked until all connected slots are completed, which is not necessarily a good idea. However, if you want to use a non-blocking connection, the execution order depends on whether the slots were executed.

It is important that each QThread has its own event queue. This means that execution order is guaranteed only for slots of a given stream. This means that you must consider the following cases:

• the signal1 slot and the signal2 slot are defined in a QObject living in the same thread: in this case, you can be sure that the slots are executed in the expected order, because they are triggered by the same event queue
• both slots work in different threads: here you do not control the execution order, since the signals are sent to 2 independent event queues. If so, you should use mutexes or wait conditions (or use a blocking connection).

Answer 2

I'm not sure if I understand you correctly, but this may help you:

When a signal is issued, the slots connected to it are usually executed immediately, like a normal function call.

from http://doc.qt.io/qt-5/signalsandslots.html

So think of calling emit () as calling any other function.

Answer 3

emit is just syntactic sugar, look at the .cpp generated by the meta object compiler (moc).

So emit signal1(); compiled as signal1(); , and the answer to your question is YES, but, of course, you have no supporters that the execution of signal1 () ends before calling signal2 ().