Are signals and slots thread safe?

[Cruz]

Is it thread safe to exchange data between threads using signals and slots, such that the signal is emitted in the sending thread and the slot is executed in the receiving thread, i.e. using queued connections?

And if so, is this also true for passing implicitely shared containers?

[high_flyer]

http://doc.trolltech.com/latest/threads-qobject.html#signals-and-slots-across-threads

[Cruz]

I have read that passage many times and it doesn't explicitely say that using queued connections is thread safe. The best clue is perhaps the Mandelbrot example, that uses queued connections to transfer a QImage and no mutex or anything is used to protect access. But still, before I believe it, I would like to hear someone saying it out loud. :)

[high_flyer]

This passage says:

Queued Connection: The slot is invoked when control returns to the event loop of the receiver's thread. The slot is executed in the receiver's thread.
And if this is not explicit enough, then the previous chapter states:

Threads and QObjects

QThread inherits QObject. It emits signals to indicate that the thread started or finished executing, and provides a few slots as well.

More interesting is that QObjects can be used in multiple threads, emit signals that invoke slots in other threads, and post events to objects that "live" in other threads. This is possible because each thread is allowed to have its own event loop.

[Cruz]

I don't mean to be a pest, but no. For me this is not explicit enough. It says that connections can be made between threads and that slots are executed in the receiver's thread, but how and why is that thread safe? If I wasn't using signals and slots and just call a setter method to copy data from one thread to another, and some method uses the data in the receiver thread when control returns to it it sounds like exactly the same procedure, but it's not thread safe.

[high_flyer]

It says that connections can be made between threads and that slots are executed in the receiver's thread, but how and why is that thread safe?
Because the execution is kept in the respecting threads.
It means that when you emit a signal from thread A, the slot it is connected to runs in thread B - which is not the same as thread A running the slot which lives in thread B, but thread B will run its own slot, triggered by the signal (event) it received form thread A.
So what is NOT thread safe about it?

Queued connection means basically, that you signals are translated to events, which are posted to the target thread.

[wysota]

For me this is not explicit enough.
Let's make it explicit then. Just please explicitly state whether you are asking about making signal-slots connections or what? Emitting signals? Executing slots? What exactly? Concepts are not thread-safe, code can be thread-safe so let's talk about code and not concepts.

[nish]

only the call to a slot is thread safe, if you are using some shared data between your threads ( and using it in that particular slot ), then you still have to protect it.

[MarekR22]

Is it thread safe to exchange data between threads using signals and slots, ...
And if so, is this also true for passing implicitly shared containers?
If you are passing in connection Qt containers by const reference or a value (shallow copy is made) it is thread safe. If one of threads will make some changes in container it will automatically create a deep copy in thread safe manner, that is way Qt documentation recommends to avoid use of operator[] (it is not const so it will create deep copy if needed) if you only read values.
If you are passing those by reference or pointer then you have to maintain thread safety.

[Cruz]

Ok, here is the code as requested:


class Thread : QThread
{
TransportObject transportObject;

public slots:
objectIn(TransportObject);
}

Thread::Thread(QObject *parent) : QThread(parent)
{
moveTothread(this); // Thread handles it's own event loop hack.
start();
}

Thread::run()
{
forever
{
process(transportObject); // do something with transportObject
QApplication::processEvents(); // handle pending events
msleep(10);
}
}

Thread::objectIn(TransportObject to)
{
this->transportObject = to;
}

main
{
Thread thread;
TransportObject transportObject;
connect(this, SIGNAL(objectOut(TransportObject)), &thread, SLOT(objectIn(TransportObject)));
...
emit objectOut(transportObject);
}

[MarekR22]

if TransportObject is QList or QVector or other Qt container then it is fine.

edit: But moving thread to it slef is a bad thing (lets asume that you will connect to deleteLater for thread then you are in big trouble).

[Cruz]

if TransportObject is QList or QVector or other Qt container then it is fine.

TransportObject has a custom struct, a QHash and a QList. Is it still fine then?




But moving thread to it slef is a bad thing (lets asume that you will connect to deleteLater for thread then you are in big trouble).

Can you explain what happens if I connect to deleteLater()? So far I haven't encoutered any problems with moving a thread to itself. And the one line of code needed to do it is very nice compared to this construction (http://www.qtcentre.org/threads/40593-Using-QTimer-in-a-QThread?p=187647#post187647).

[MarekR22]

If this structure doesn't contain any pointers then it should be Ok. Qt will crete copy from those data so you don't have to synchronize anything.

About moving thread to it self: deleteLater will try to delete QThread and when it is moved to it self deletion will be performed inside this thread, so it can't be finished properly since it will try to destroy event loop which is currently processed. Similar problem you will have when using start slot of QThread (use of not existing event loop).