Ok, I think I am understanding this a bit now. By not decrementing the
signaled count, we are allowing a single broadcast to wake up the same
thread multiple times, and are allowing a single cond_signal to wake up
My understanding was that this behavior was not right, but upon further
inspection of the pthreads documentation this behavior seems to be
Thanks for the clarifications,
Gleb Natapov wrote:
> On Thu, Dec 06, 2007 at 09:46:45AM -0500, Tim Prins wrote:
>> Also, when we are using threads, there is a case where we do not
>> decrement the signaled count, in condition.h:84. Gleb put this in in
>> r9451, however the change does not make sense to me. I think that the
>> signal count should always be decremented.
>> Can anyone shine any light on these issues?
> I made this change a long time ago (I wander why I even tested threaded
> build back then), but what I recall looking into the code and log message
> there was a deadlock when signal broadcast doesn't wake up all thread
> that are waiting on a conditional variable. Suppose two threads wait on
> a condition C, third thread does broadcast. This makes C->c_signaled to
> be equal 2. Now one thread wakes up and decrement C->c_signaled by one.
> And before other thread is starting to run it calls condition_wait on C
> one more time. Because c_signaled is 1 it doesn't sleep and decrement
> c_signaled one more time. Now c_signaled is zero and when second thread
> wakes up it see this and go to sleep again. The solution was to check in
> condition_wait if condition is already signaled before go to sleep and
> if yes exit immediately.
> devel mailing list