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!


  • Qt Champions 2016

    @qtpi
    If you don't provide a connection type to QObject::connect, it is; in the sense that it's executed from the signal.
    But(!) calling the slot directly may be dangerous.

    Kind regards.



  • @kshegunov

    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.


  • Qt Champions 2016

    @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.



  • @kshegunov

    Yes, but only if they have the same thread-affinity. Your statement would be incorrect if the objects are living in different threads.


  • Qt Champions 2016

    @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 to Qt::QueuedConnection.



  • @kshegunov

    Ah missed it :)



  • @kshegunov

    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.


  • Qt Champions 2016

    @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 with Qt::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.



  • @kshegunov

    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.


  • Qt Champions 2016

    @qtpi said:

    So I was worried about the synchronization problem if more than one driver are started.

    Just make an ordinary connect from his/hers signal to your slot and don't worry about the sync, Qt will do it for you.


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.