[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

Torvald Riegel <triegel at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |triegel at redhat dot com

--- Comment #5 from Torvald Riegel <triegel at redhat dot com> 2012-09-18 14:18:13 UTC ---
(In reply to comment #2)
> Can you take another look at this please?  It isn't about fairness because the
> man page (and spec AFAIK) for pthread_cond_signal says:
> 
> "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)."
> 
> In the example, only thread A is blocked at the time thread B signals for the
> first time, so I think it should wake whatever happens later  The blocking of
> threads C and D occurs after thread B signals for the first time so shouldn't
> be affected by that signal.

Please revise your test case so that it is properly synchronized for what you
intend to test.  usleep() is not a reliable way to enforce a happens-before
order between operations in different threads.  Cond vars, locks, or something
similar can enforce happens-before.

> The problem is that if pthread_cond_timedwait in thread D reaches its timeout
> before thread A has had a chance to increment __woken_seq, then thread D will
> claim the signal even though its true reason for waking is the timeout.

If A didn't consume a signal before D did, why shouldn't D consume an available
signal?  The manpage bit you quote says that _at least_ one of the blocked
threads should be unblocked.  This seems to be what's happening.

If you find a statement in the spec that disallows the behavior you see, please
quote this statement instead.  I guess what you might find to be surprising is
that a signal operation might not have finished wakening a thread even though
it already returned to the caller.

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