pthread_cond_signal query

Started by
0 comments, last by cbirkhold 16 years, 11 months ago
Hi all, Need help in understanding the the behavior of pthread lib in following situation? I am getting a deadlock situation. One producer thread gives pthread_cond_signal to two different threads (one Consumer thread and other one waiting producer thread) on two different conditions before unlocking the mutex. Both of these conditions are getting fullfilled at the same time and producer thread first singals the consumer thread and then signals the waiting producer thread. After that it releases the mutex by calling unlock on it. Firstly, which thread would get the mutex? Consumer or Waiting producer thread? Secondly, If one these two threads got the mutex, what will happen to other thread? will it still wait for mutex/next singal or will get blocked forever? I am ruling out signal lose (if any) will block any thread forever, because if one thread misses any signal, it will get another signal after condition satifies. Thanks in advance!! -Tarun
Advertisement
So you have two thread (A and B) with one conditions each (Ca and Cb) that share a single mutex (M) for the wait operation? As you seem to signal both conditions individually - and assuming that no other threads are waiting for the same conditions - both thread will wake up but but only one will acquire the mutex right away (lets assume A also the order is not predictable in all cases). The other one (in our case B) will wait for the mutex to be release (by A) and then aquire the mutex itself (that of course is if no other thread is also waiting for the same mutex and gets precedence). Essentially what happens is that pthread_cond_wait() attaches the calling thread to the event, then releases/unlocks the mutex passed in as the second argument and finally sends the calling thread to sleep. If the thread is resumed (by pthread_cond_signal()) the first thing it does before returning from pthread_cond_wait() is to aquire/lock the mutex again. It is up to you to release/unlock the mutex again as appropriate.

This topic is closed to new replies.

Advertisement