The #GCond struct is an opaque data structure that represents a
condition. Threads can block on a #GCond if they find a certain
condition to be false. If other threads change the state of this
condition they signal the #GCond, and that causes the waiting
threads to be woken up.
Consider the following example of a shared variable. One or more
threads can wait for data to be published to the variable and when
another thread publishes the data, it can signal one of the waiting
threads to wake up to collect the data.
Here is an example for using GCond to block a thread until a condition
is satisfied:
Whenever a thread calls pop_data() now, it will wait until
current_data is non-null, i.e. until some other thread
has called push_data().
The example shows that use of a condition variable must always be
paired with a mutex. Without the use of a mutex, there would be a
race between the check of @current_data by the while loop in
pop_data() and waiting. Specifically, another thread could set
@current_data after the check, and signal the cond (with nobody
waiting on it) before the first thread goes to sleep. #GCond is
specifically useful for its ability to release the mutex and go
to sleep atomically.
It is also important to use the glib.cond.Cond.wait and glib.cond.Cond.waitUntil
functions only inside a loop which checks for the condition to be
true. See glib.cond.Cond.wait for an explanation of why the condition may
not be true even after it returns.
If a #GCond is allocated in static storage then it can be used
without initialisation. Otherwise, you should call glib.cond.Cond.init_
on it and glib.cond.Cond.clear when done.
A #GCond should only be accessed via the g_cond_ functions.
The #GCond struct is an opaque data structure that represents a condition. Threads can block on a #GCond if they find a certain condition to be false. If other threads change the state of this condition they signal the #GCond, and that causes the waiting threads to be woken up.
Consider the following example of a shared variable. One or more threads can wait for data to be published to the variable and when another thread publishes the data, it can signal one of the waiting threads to wake up to collect the data.
Here is an example for using GCond to block a thread until a condition is satisfied:
Whenever a thread calls pop_data() now, it will wait until current_data is non-null, i.e. until some other thread has called push_data().
The example shows that use of a condition variable must always be paired with a mutex. Without the use of a mutex, there would be a race between the check of @current_data by the while loop in pop_data() and waiting. Specifically, another thread could set @current_data after the check, and signal the cond (with nobody waiting on it) before the first thread goes to sleep. #GCond is specifically useful for its ability to release the mutex and go to sleep atomically.
It is also important to use the glib.cond.Cond.wait and glib.cond.Cond.waitUntil functions only inside a loop which checks for the condition to be true. See glib.cond.Cond.wait for an explanation of why the condition may not be true even after it returns.
If a #GCond is allocated in static storage then it can be used without initialisation. Otherwise, you should call glib.cond.Cond.init_ on it and glib.cond.Cond.clear when done.
A #GCond should only be accessed via the g_cond_ functions.