glibmm: Glib::Threads::Cond Class Reference

An opaque data structure to represent a condition. More...

#include <glibmm/threads.h>

Public Member Functions

 Cond ()
 
 Cond (const Cond&)=delete
 
Condoperator= (const Cond&)=delete
 
 ~Cond ()
 
void signal ()
 If threads are waiting for this Cond, exactly one of them is woken up. More...

 
void broadcast ()
 If threads are waiting for this Cond, all of them are woken up. More...

 
void wait (Mutex& mutex)
 Waits until this thread is woken up on this Cond. More...

 
bool wait_until (Mutex& mutex, gint64 end_time)
 Waits until this thread is woken up on this Cond, but not longer than until the time specified by end_time. More...

 
GCond* gobj ()
 

Detailed Description

An opaque data structure to represent a condition.

A Cond is an object that threads can block on, if they find a certain condition to be false. If other threads change the state of this condition they can signal the Cond, such that the waiting thread is woken up.

Deprecated:
Please use std::condition_variable instead.
Usage example:
void* current_data = nullptr;
void push_data(void* data)
{
current_data = data;
data_cond.signal();
}
void* pop_data()
{
while (!current_data)
data_cond.wait(data_mutex);
void* const data = current_data;
current_data = nullptr;
return data;
}

Constructor & Destructor Documentation

Glib::Threads::Cond::Cond ( )
Glib::Threads::Cond::Cond ( const Cond )
delete
Glib::Threads::Cond::~Cond ( )

Member Function Documentation

void Glib::Threads::Cond::broadcast ( )

If threads are waiting for this Cond, all of them are woken up.

It is good practice to hold the same lock as the waiting threads, while calling this method, though not required.

GCond* Glib::Threads::Cond::gobj ( )
inline
Cond& Glib::Threads::Cond::operator= ( const Cond )
delete
void Glib::Threads::Cond::signal ( )

If threads are waiting for this Cond, exactly one of them is woken up.

It is good practice to hold the same lock as the waiting thread, while calling this method, though not required.

void Glib::Threads::Cond::wait ( Mutex mutex)

Waits until this thread is woken up on this Cond.

The mutex is unlocked before falling asleep and locked again before resuming.

Parameters
mutexA Mutex that is currently locked.
Note
It is important to use the wait() and wait_until() methods only inside a loop, which checks for the condition to be true as it is not guaranteed that the waiting thread will find it fulfilled, even if the signaling thread left the condition in that state. This is because another thread can have altered the condition, before the waiting thread got the chance to be woken up, even if the condition itself is protected by a Mutex.
bool Glib::Threads::Cond::wait_until ( Mutex mutex,
gint64  end_time 
)

Waits until this thread is woken up on this Cond, but not longer than until the time specified by end_time.

The mutex is unlocked before falling asleep and locked again before resuming.

Usage example:
Extending the example presented in the documentation of class Cond.
void* pop_data_timed()
{
// Wait at most 5 seconds.
const gint64 end_time = g_get_monotonic_time() + 5* G_TIME_SPAN_SECOND;
while (!current_data)
if (!data_cond.wait_until(data_mutex, end_time)
return nullptr; // timeout
void* const data = current_data;
current_data = nullptr;
return data;
}
The end time is calculated once, before entering the loop, and reused. This is the motivation behind the use of absolute time. If a relative time of 5 seconds were passed directly to the call and a spurious wakeup occurred, the program would have to start over waiting again, which would lead to a total wait time of more than 5 seconds.
Parameters
mutexA Mutex that is currently locked.
end_timeThe monotonic time to wait until, in microseconds. See g_get_monotonic_time().
Returns
true if the condition variable was signalled (or in the case of a spurious wakeup), false if end_time has passed.
Note
It is important to use the wait() and wait_until() methods only inside a loop, which checks for the condition to be true as it is not guaranteed that the waiting thread will find it fulfilled, even if the signaling thread left the condition in that state. This is because another thread can have altered the condition, before the waiting thread got the chance to be woken up, even if the condition itself is protected by a Mutex.