[Bug nptl/12875] pthread_cond_timedwait can steal the wakeup of slower thread in pthread_cond_wait

["triegel at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=12875

--- Comment #9 from Torvald Riegel <triegel at redhat dot com> 2012-09-19 08:21:49 UTC ---
(In reply to comment #7)
> > If so, please quote the specification or manpage that this violates.  At the
> > very least, we need this for documentation purposes.
> 
> "The pthread_cond_signal() function shall unblock at least one of the threads
> that are blocked on the specified condition variable cond (if any threads are
> blocked on cond)."
> 
> Source:
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_cond_signal.html
> 
> If it's provable that threads 1 through N are waiting on a condition variable C
> when thread X calls pthread_cond_signal on C N times, then in order to satisfy
> the above, all N must be unblocked.

First, I don't think you can prove that they are waiting in this test case --
usleep doesn't give you any happens-before or other ordering guarantees.

Second, the sentence from the spec that you quote is vague on when those other
threads would block (e.g., is there any guarantee of linearizability or such?).
Specifically, it doesn't state which blocked threads should be wakened, or
which threads blocked at which time.

> If another waiter arriving after the N
> signals consumes any of the signals and prevents those N from being blocked,
> then the above cited requirement has been violated;

I don't see how this is violated. You say it unblocked the waiter and N-1 other
threads, so N overall for N signals.  That's what the guarantee is, isn't it?

> at least one call to
> pthread_cond_signal did not "unblock at least one of the threads that are
> blocked".

It did unblock one of the threads that are blocked.  Even at the end right
before their timeout they are still blocked, right?

> I admit the test case is poorly written and rather obfuscated but I believe
> that it is showing a bug of this nature.

> Contrary to yours and Mr. Dreppers
> characterizations, this is NOT A FAIRNESS ISSUE.

Please look again at the paragraph that you wrote that I replied to in comment
#6.  You describe a fairness issue there (a newer waiter "stealing" an older
waiter's signal).  I did not say that this bug report is just a fairness issue.
 In some executions it might show that there's no fairness, but the core
problems with this bug report are the two items I point out above.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.