[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 #6 from Torvald Riegel <triegel at redhat dot com> 2012-09-18 14:28:05 UTC ---
(In reply to comment #3)
> This is definitely a bug.

If so, please quote the specification or manpage that this violates.  At the
very least, we need this for documentation purposes.

> I hope this won't be another case where Mr. Drepper
> has got too much time invested in the over-engineered code for minimizing
> spurious wakes to admit that it needs to be thrown out and replaced with a
> correct implementation.

This is a bug report.  Please focus on the technical matter.

> Actually I have a possible alternate explanation for his position: it's
> possible that he's viewing condition signals as events that always correspond
> to a new item in a queue that will be removed by any waiter who wakes. If this
> is all you use cond vars for, there's no need to avoid having a new waiter
> (arriving after the signal) avoid stealing an existing waiter's wake, because
> the new waiter could just as easily have experienced a spurious wake, and upon
> waking up and checking the queue, found and removed the next queued item - at
> which point, even if the existing waiter woke, it would find an empty queue
> again and wait again.

What you describe is a fairness issue.  I'm not aware of any guarantee of
fairness or absence of starvation.  The cond var should try to be fair if
possible, but the test case is not even for a PI cond var, so threads aren't
even guaranteed to get to run on the CPU.

> Of course condition variables have plenty of other legitimate uses, and the
> requirements on the implementation are governed by the specification, not by
> one narrow-minded idea of what they should be used for...

So, please cite the bits of the specification that disallow the behavior.  What
Martin cite from the manpage does not seem to conflict with the current
behavior.

-- 
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.