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

["martin at lispworks dot com" <sourceware-bugzilla@sourceware.org>]

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

martin at lispworks dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #5787|0                           |1
        is obsolete|                            |

--- Comment #15 from martin at lispworks dot com 2012-09-20 14:01:28 UTC ---
Created attachment 6639
  --> http://sourceware.org/bugzilla/attachment.cgi?id=6639
Test case with explicit happens-before logic rather than usleep

As requested, I've attached a version of the test case that uses the lock,
barriers and atomic instructions to enforce happens-before.  There are 2
remaining calls to usleep, which are needed to ensure ordering between the
calling thread and the internals of pthread_cond_wait than can't be controlled.

This bug may be different from Bug 13165, because it is caused by waking from a
timeout rather than an extra signal.

Why I think this is a bug: my reading of the sentence "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)." is that it only affects threads that "are blocked" at the
time pthread_cond_signal() is called, not those that call pthread_cond_wait
afterwards.  The wording for pthread_cond_broadcast() says "currently blocked",
but is that an intentional difference?

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