QMutex & QWaitCondition usage

rtavakko

Hey guys,

I'm trying to understand and clarify how to use QMutex and QWaitCondition for synchronization across two threads. Let's say I have a producer and consumer object like in the wait conditions example.

The producer creates an array of data and sends it to the consumer to read. And the consumer is expected to notify the producer when it is finished reading the data.

The producer class would be something like this:

class Producer : public QThread
{
    Q_OBJECT
private:
    QMutex readMutex;
    QWaitCondition readCondition;
    
    unsigned char* data = nullptr;
    
public:
    Producer(QObject *parent = NULL) : QThread(parent)
    {
    }

    void run() override
    {
        data = new unsigned char[8];
        memset(data, 255, 8*sizeof(unsigned char));
        
        mutex.lock();
        emit dataReady(data, &readMutex, &readCondition);
        readCondition.wait(&mutex);
        delete data;
        data = nullptr;
        mutex.unlock();
    }

signals:
    void dataReady(unsigned char* readData, QMutex* mutex, QWaitCondition* condition);
};

And the consumer class would be:

class Consumer : public QThread
{
public:
    Consumer(QObject *parent = NULL) : QThread(parent)
    {
    }
public slots:
    void processData(unsigned char* readData, QMutex* mutex, QWaitCondition* condition)
    {
        //Data processing stuff//
        
        QMutexLocker(mutex);
        condition -> notify_all();
    }
};

Would this be the correct use of the mechanism? Does the consumer need to do anything with the mutex at all or does it only need the wait condition so it can notify the producer?

Cheers!

rtavakko

It seems what I'm seeing is the spurious / lost wake up side effect build into the wait condition mechanism especially given that this is a very basic example. I have yet to do more testing with this but so far it seems adding a simple method similar to this in the worker thread fixes the issue:

bool readPredicate = false;
unsigned long t_readTimeOut = 50;

bool Producer::waitForFrameRead()
{
    bool timedOut = false;
    while(!readPredicate)
    {
        timedOut = !frameProcessed.wait(&mutex, t_readTimeOut);
    }
    return timedOut;
}

The consumer would access the readPredicate boolean and set it to true when it is done processing data.

I'm not sure if this is the best way to get around the issue, I would definitely appreciate it if anyone with experience on this can share their knowledge.

Cheers!

Christian Ehrlicher

Please take a look at https://doc.qt.io/qt-5/qtcore-threads-waitconditions-example.html

rtavakko

@Christian-Ehrlicher Thanks. I've based the code I posted above on the example. What I'm not sure about is if the consumer only needs to notify the producer or if it also needs to lock and unlock the mutex.

Christian Ehrlicher

The exmaple is correct, so why do you want to use an extra mutex?

rtavakko

I have multiple producers working with one consumer. After a few cycles, the consumer fails to wake up one of the producers. It sends the wake signal but it is never received. If I put in the QMutexLocker line it works ok:

QMutexLocker(mutex);
condition -> notify_all();

I'm not sure why this happens but it seems to happen more often during keyboard events, switching between different windows etc.

In the producer do I need to use QMutexLocker instead of locking and unlocking the mutex?

rtavakko

This post is deleted!

rtavakko

It seems what I'm seeing is the spurious / lost wake up side effect build into the wait condition mechanism especially given that this is a very basic example. I have yet to do more testing with this but so far it seems adding a simple method similar to this in the worker thread fixes the issue:

bool readPredicate = false;
unsigned long t_readTimeOut = 50;

bool Producer::waitForFrameRead()
{
    bool timedOut = false;
    while(!readPredicate)
    {
        timedOut = !frameProcessed.wait(&mutex, t_readTimeOut);
    }
    return timedOut;
}

The consumer would access the readPredicate boolean and set it to true when it is done processing data.

I'm not sure if this is the best way to get around the issue, I would definitely appreciate it if anyone with experience on this can share their knowledge.

Cheers!