a signal emitted by QMutexLocker locked funtion, will the SLOT connected with this signal also be locked?
-
func1()
{
QMutexLocker locker(&mutex);
emit signal1();
}
connect(this,SIGNAL(signal1()),this,SLOT(slot1()));slot1();
so the question is is slot1() also mutexlocked?
thanks in advance!
-
@qtpi
If you don't provide a connection type toQObject::connect, it is; in the sense that it's executed from the signal.
But(!) calling the slot directly may be dangerous.Kind regards.
-
Are you sure? I believe if a slot is called directly or not depended on the thread-affinity of the signal emitting object and the signal receiving object.
@t3685
By directly I meant invoked as a regular function. E.g.:MyClass::MyClass(QObject * parent) : QObject(parent); { QObject::connect(this, &MyClass::mySignal, this, &MyClass::mySlot); //< Same thread affinity, always, thus Qt::DirectConnection } void MyClass::mySlot() { // Do something dangerous here. } void MyClass::someFunction() { QMutexLocker locker(&mutex); emit mySignal(); //< Safe, 'cause Qt::DirectConnection } void MyClass::someBadFunction() { mySlot(); //< Ooops! I didn't mean to generate a race condition. }Kind regards.
-
@t3685
By directly I meant invoked as a regular function. E.g.:MyClass::MyClass(QObject * parent) : QObject(parent); { QObject::connect(this, &MyClass::mySignal, this, &MyClass::mySlot); //< Same thread affinity, always, thus Qt::DirectConnection } void MyClass::mySlot() { // Do something dangerous here. } void MyClass::someFunction() { QMutexLocker locker(&mutex); emit mySignal(); //< Safe, 'cause Qt::DirectConnection } void MyClass::someBadFunction() { mySlot(); //< Ooops! I didn't mean to generate a race condition. }Kind regards.
Yes, but only if they have the same thread-affinity. Your statement would be incorrect if the objects are living in different threads.
-
Yes, but only if they have the same thread-affinity. Your statement would be incorrect if the objects are living in different threads.
@t3685
This line from the original post:connect(this,SIGNAL(signal1()),this,SLOT(slot1()));guarantees they have the same thread affinity.
PS.
It'd be pretty useless to have a mutex at all if they're in different threads, as the connection would default toQt::QueuedConnection. -
@t3685
This line from the original post:connect(this,SIGNAL(signal1()),this,SLOT(slot1()));guarantees they have the same thread affinity.
PS.
It'd be pretty useless to have a mutex at all if they're in different threads, as the connection would default toQt::QueuedConnection.Ah missed it :)
-
Yes, but only if they have the same thread-affinity. Your statement would be incorrect if the objects are living in different threads.
that is actually good point. In my file I did try to connect this signal with a slot that is running in main thread, the mutexlock will have no effect due to the fact two threads have different affinity.
I wrote as in post cause I want to make it simpler. But now I fully understand how it works.
thank both of you.
-
that is actually good point. In my file I did try to connect this signal with a slot that is running in main thread, the mutexlock will have no effect due to the fact two threads have different affinity.
I wrote as in post cause I want to make it simpler. But now I fully understand how it works.
thank both of you.
@qtpi
You shouldn't need to have mutexes at all when doing signal-slot connections. Qt's designed in such a way that slot invocations are serialized to the thread the receiver lives in when connections are made withQt::AutoConnection. You need to have a mutex, when you need a mutual exclusion lock. In your case I don't see a reason to have one at all, and to be honest most of the time you won't need it.
Perhaps if you expand on what you want to do, we might be able to give some better advice/alternative.Kind regards.
-
@qtpi
You shouldn't need to have mutexes at all when doing signal-slot connections. Qt's designed in such a way that slot invocations are serialized to the thread the receiver lives in when connections are made withQt::AutoConnection. You need to have a mutex, when you need a mutual exclusion lock. In your case I don't see a reason to have one at all, and to be honest most of the time you won't need it.
Perhaps if you expand on what you want to do, we might be able to give some better advice/alternative.Kind regards.
nah, I am trying to editing someone's code, and his driver function is a thread that will emit a signal once a new msg is received.
I am trying to work on the msg and write some function to react to these incoming msgs. My function is in another class, which will be run in main thread. So I was worried about the synchronization problem if more than one driver are started.
-
nah, I am trying to editing someone's code, and his driver function is a thread that will emit a signal once a new msg is received.
I am trying to work on the msg and write some function to react to these incoming msgs. My function is in another class, which will be run in main thread. So I was worried about the synchronization problem if more than one driver are started.
