Equivalent to boost::condition_variable

[SPlatten]

I'm trying to remove boost references in the project I'm updating, in the class prototype there is a member declared as:

boost::condition_variable m_ReadyCondition;

In the implementation:

m_serverReadyCondition.wait(lock, [this]() { return m_serverReady; });

Where lock is was defined as:

boost::unique_lock<boost::mutex> lock;

I've replaced all the instances of mutex with QMutex, is there a Qt equivalent of the boost::condition_variable ?

[jsulm]

@SPlatten There is https://doc.qt.io/qt-5/qwaitcondition.html or if you want C++ stdlib there is https://en.cppreference.com/w/cpp/thread/condition_variable

[jsulm]

@SPlatten There is https://doc.qt.io/qt-5/qwaitcondition.html or if you want C++ stdlib there is https://en.cppreference.com/w/cpp/thread/condition_variable

[SPlatten]

Thank you, just found this after a google immediately after posting.

[SPlatten]

@jsulm , I'm trying to implement QWaitCondition, is there an equivalent to exit the wait ?

[jsulm]

@SPlatten I'm not sure what you mean. There are notify* and wake* methods.

[SPlatten]

The original class has a method:

void className::waitForServerReady() {
    boost::unique_lock<boost::mutex> lock(*this);
    m_serverReadyCondition.wait(lock, [this]() { return m_serverReady; });
}

I've replaced the boost::unique_lock and boost::mutex with:

QMutexLocker lock(&m_mutex);

Where m_mutex is now defined as:

mutable QMutex m_mutex;

And in the class constructor:

m_mutex(QMutex::Recursive)

In the original class, m_serverReadyCondition is defined as:

boost::condition_variable m_serverReadyCondition;

Which I've replaced with:

QWaitCondition m_serverReadyCondition;

m_serverReady is a bool.

[JKSH]

@SPlatten said in Equivalent to boost::condition_variable:

I'm trying to implement QWaitCondition, is there an equivalent to exit the wait ?

...

void className::waitForServerReady() {
    boost::unique_lock<boost::mutex> lock(*this);
    m_serverReadyCondition.wait(lock, [this]() { return m_serverReady; });
}

The "exit" function is called the predicate.

QWaitCondition doesn't accept a predicate, but you can implement your own checks in a while loop: https://stackoverflow.com/questions/33692574/stdcondition-variablewait-with-predicate

[SPlatten]

@JKSH , In the class there is a method to modify the boolean m_serverReady, when this is set to true it also calls:

m_serverReadyCondition.notify_all();

Will that be enough?

[JKSH]

@SPlatten said in Equivalent to boost::condition_variable:

@JKSH , In the class there is a method to modify the boolean m_serverReady, when this is set to true it also calls:

m_serverReadyCondition.notify_all();

Will that be enough?

That's not enough. You should check the predicate to avoid a lost wakeup which can cause a deadlock: https://www.modernescpp.com/index.php/c-core-guidelines-be-aware-of-the-traps-of-condition-variables

[SPlatten]

@JKSH , all those examples are using std::condition_variable which looks like a close match to the boost::condition_variable.

I can't see a similar way of doing the same with QWaitCondition.

[JKSH]

@SPlatten said in Equivalent to boost::condition_variable:

@JKSH , all those examples are using std::condition_variable which looks like a close match to the boost::condition_variable.

I can't see a similar way of doing the same with QWaitCondition.

QWaitCondition behaves just like std::condition_variable and boost::condition_variable. The only difference is that QWaitCondition::wait() doesn't take a lambda.

Look closely at the examples again. How can you replace the lambda with a while loop?

[SPlatten]

@JKSH , so for example if I take:

m_serverReadyCondition.wait(lock, [this]() { return m_serverReady; });

And replace with:

while( !m_serverReady ) {
    m_serverReadyCondition.wait(lock);
}

Would that be ok?

[JKSH]

@SPlatten said in Equivalent to boost::condition_variable:

@JKSH , so for example if I take:

m_serverReadyCondition.wait(lock, [this]() { return m_serverReady; });

And replace with:

while( !m_serverReady ) {
    m_serverReadyCondition.wait(lock);
}

Would that be ok?

Looks good to me