Atomically releases mutex and waits until cond is signalled.
When this function returns, mutex is locked again and owned by the
calling thread.
When using condition variables, it is possible that a spurious wakeup
may occur (ie: g_cond_wait() returns even though g_cond_signal() was
not called). It's also possible that a stolen wakeup may occur.
This is when g_cond_signal() is called, but another thread acquires
mutex before this thread and modifies the state of the program in
such a way that when g_cond_wait() is able to return, the expected
condition is no longer met.
For this reason, g_cond_wait() must always be used in a loop. See
the documentation for GCond for a complete example.
Atomically releases mutex and waits until cond is signalled. When this function returns, mutex is locked again and owned by the calling thread. When using condition variables, it is possible that a spurious wakeup may occur (ie: g_cond_wait() returns even though g_cond_signal() was not called). It's also possible that a stolen wakeup may occur. This is when g_cond_signal() is called, but another thread acquires mutex before this thread and modifies the state of the program in such a way that when g_cond_wait() is able to return, the expected condition is no longer met. For this reason, g_cond_wait() must always be used in a loop. See the documentation for GCond for a complete example.