QWaitCondition(3qt)

📦 version 3.3.8b, in fedora 43, fedora 44

okay bestie, pull up a chair, we're doing QWaitCondition(3qt) today and it's literally gonna be fine 💖

🌸 NAME 🌸

QWaitCondition — Allows waiting/waking for conditions between threads

✨ SYNOPSIS ✨

All the functions in this class are thread-safe when Qt is built with thread support.</p>

#include <qwaitcondition.h>

🫶 Public Members

  • QWaitCondition ()
  • virtual ~QWaitCondition ()
  • bool wait ( unsigned long time = ULONG_MAX )
  • bool wait ( QMutex * mutex, unsigned long time = ULONG_MAX )
  • void wakeOne ()
  • void wakeAll ()

💅 DESCRIPTION 💅

The QWaitCondition class allows waiting/waking for conditions between threads. that's the whole vibe, that's the assignment, periodt.

So here's the tea 🍓: QWaitConditions let a thread tell other threads that some sort of condition has been met. One or many threads can block waiting for a QWaitCondition to set a condition with wakeOne() or wakeAll(). Use wakeOne() to wake one randomly selected event, or wakeAll() to wake them all. pick your fighter.

For example, say we have three tasks that should be performed every time the user presses a key; each task could be split into a thread, each of which would have a run() body like this:

QWaitCondition key_pressed;
for (;;) {
    key_pressed.wait(); // This is a QWaitCondition global variable
    // Key was pressed, do something interesting
    do_something();
}

A fourth thread would read key presses and wake the other three threads up every time it receives one, like this:

QWaitCondition key_pressed;
for (;;) {
    getchar();
    // Causes any thread in key_pressed.wait() to return from
    // that method and continue processing
    key_pressed.wakeAll();
}

⚠️ heads up bestie, this part matters: note that the order the three threads are woken up in is undefined, and that if some or all of the threads are still in do_something() when the key is pressed, they won't be woken up (since they're not waiting on the condition variable) and so the task will not be performed for that key press. it's giving chaos, honestly. This can be avoided by, for example, doing something like this:

QMutex mymutex;
QWaitCondition key_pressed;
int mycount=0;
// Worker thread code
for (;;) {
    key_pressed.wait(); // This is a QWaitCondition global variable
    mymutex.lock();
    mycount++;
    mymutex.unlock();
    do_something();
    mymutex.lock();
    mycount--;
    mymutex.unlock();
}
// Key reading thread code
for (;;) {
    getchar();
    mymutex.lock();
    // Sleep until there are no busy worker threads
    while( mycount > 0 ) {
        mymutex.unlock();
        sleep( 1 );
        mymutex.lock();
    }
    mymutex.unlock();
    key_pressed.wakeAll();
}

The mutexes are necessary because the results of two threads attempting to change the value of the same variable simultaneously are unpredictable 😭 — that's not a vibe, that's a data race.

See also Environment Classes and Threading.

👑 MEMBER FUNCTION DOCUMENTATION 👑

QWaitCondition::QWaitCondition ()

Constructs a new event signalling, i.e. wait condition, object. fresh out the box, no notes. 🎀

QWaitCondition::~QWaitCondition () [virtual]

Deletes the event signalling, i.e. wait condition, object. gone but never forgotten 🦋

bool QWaitCondition::wait ( unsigned long time = ULONG_MAX )

Wait on the thread event object. The thread calling this will block until either of these conditions is met:

  • Another thread signals it using wakeOne() or wakeAll(). This function will return TRUE in this case.
  • time milliseconds has elapsed. If time is ULONG_MAX (the default), then the wait will never timeout (the event must be signalled). This function will return FALSE if the wait timed out.

See also wakeOne() and wakeAll().

bool QWaitCondition::wait ( QMutex * mutex, unsigned long time = ULONG_MAX )

This is an overloaded member function, provided for convenience. It behaves essentially like the above function. same energy, extra ingredient ✨

Release the locked mutex and wait on the thread event object. The mutex must be initially locked by the calling thread. If mutex is not in a locked state, this function returns immediately. If mutex is a recursive mutex, this function returns immediately. fr fr, no waiting around in those two cases. The mutex will be unlocked, and the calling thread will block until either of these conditions is met:

  • Another thread signals it using wakeOne() or wakeAll(). This function will return TRUE in this case.
  • time milliseconds has elapsed. If time is ULONG_MAX (the default), then the wait will never timeout (the event must be signalled). This function will return FALSE if the wait timed out.

The mutex will be returned to the same locked state. This function is provided to allow the atomic transition from the locked state to the wait state. atomic transition?? she's a main character for real. 💅

See also wakeOne() and wakeAll().

void QWaitCondition::wakeAll ()

This wakes all threads waiting on the QWaitCondition. The order in which the threads are woken up depends on the operating system's scheduling policies, and cannot be controlled or predicted. so don't come for me about the order, it's the OS's fault 😤

See also wakeOne().

void QWaitCondition::wakeOne ()

This wakes one thread waiting on the QWaitCondition. The thread that is woken up depends on the operating system's scheduling policies, and cannot be controlled or predicted. mystery thread, love that for us 🙈

See also wakeAll().

🔍 SEE ALSO 🔍

Copyright 1992-2007 Trolltech ASA, http://www.trolltech.com. See the license file included in the distribution for a complete license statement. read the license file bestie, it's right there 🫶

✍️ AUTHOR ✍️

Generated automatically from the source code. no human author, just robot excellence 🤖✨

🐛 BUGS 🐛

If you find a bug in Qt, please report it as described in http://doc.trolltech.com/bughowto.html. Good bug reports help us to help you. Thank you. yes queen, file that bug, we appreciate you 💖

The definitive Qt documentation is provided in HTML format; it is located at $QTDIR/doc/html and can be read using Qt Assistant or with a web browser. This man page is provided as a convenience for those users who prefer man pages, although this format is not officially supported by Trolltech. we're the unofficial fan page, basically.

If you find errors in this manual page, please report them to qt-bugs@trolltech.com. Please include the name of the manual page (qwaitcondition.3qt) and the Qt version (3.3.8). include the version, i am begging you 🙏

and that's a wrap bestie!! this page came to you courtesy of Trolltech AS, dated 2 February 2007, and it's talking about Qt version 3.3.8 — and honestly? the way this class handles thread conditions is iconic, no cap. go forth and wakeAll() responsibly. 💖✨🎀

📦 where this page comes from