2 ways to break out of pthread_cond_wait() - which is better?
The condition that caused the wait must be re-tested before continuing execution from the point of the pthread_cond_wait(). The recommended method is to use a loop:
pthread_mutex_lock();
while (condition_is_false)
pthread_cond_wait();
pthread_mutex_unlock();
Now, I also want the thread to unblock itself if another_condition is true. Let's say this another_condition is not shared and thus does not need protection. I have 2 ways to do it:
1.
pthread_mutex_lock();
while (condition_is_false && !another_condition)
pthread_cond_wait();
pthread_mutex_unlock();
2. Keep the original loop and do the following to cheat the signal/wait mechanism into thinking that condition_is_false is no longer false:
When I set another_condition to true, I also do this:
set condition_is_false to condition_is_true (temporarily)
pthread_cond_signal();
set condition_is_false back to condition_is_false
Which is better? A better third way?
[1035 byte] By [
minglai] at [2007-11-26 10:35:13]
# 1
Oh, this is really should be asked on opensolaris forums, not in studio one.
What will happen if another thread (which does not depened on another condition) will wakeup
upon pthread_cond_signal() ahead of your first thread (which depend on another_condition)?
In the first case, you will test another_condition only pthread_cond_wait() returns either due
to condition becomes true or spurious wakeup. Perhaps this is not exactly what you need.
Depending on your situation, you can use pthread_cond_timedwait() or use pthread_cancel and
stuff (condition wait is a cancellation point).
Once again, this is better be asked on solaris forum, not here
# 2
If one thread is causing "another condition" to be true, and a
different thread is testing that condition, then the condition
is shared between multiple threads and it needs synchronization.
There are two basic approaches. Combine both conditions together
and sychronize them by one lock. Use the lock whenever you want to
test or change either of the conditions.
You could also use two different locks. One for each condition.
If a thread needs to guarantee that both conditions are true
FOR A PERIOD OF TIME without becoming false in the middle
of the code. Then one of your threads has to hold BOTH locks
for a period of time.
Whenever one thread holds two locks you should establish an
ordering so that lock A is always acquired before lock B.
If you ever have one thread holding lock A and waiting on lock B,
and another thread holding lock B and waiting on lock A then you
will get a deadlock. So always lock them in the same order.
(That's a general principle when working with multiple locks.)
The same basic principles apply when using condition variables.
The lock protecting the condition is the one that you use
in combination with the condition variable.
> set condition_is_false to condition_is_true (temporarily)
> pthread_cond_signal();
> set condition_is_false back to condition_is_false
This will definately NOT work. The blocking thread is not guaranteed
to wake up before the condition is set back to false.
