[Bug libgomp/51249] New: semaphore implemetation for linux leaves threads blocked

["amodra at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51249

             Bug #: 51249
           Summary: semaphore implemetation for linux leaves threads
                    blocked
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libgomp
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: amodra@gmail.com


Refer libgomp/config/linux/sem.[ch]

Threads A, B, C.  Initial sem value = 1.

A calls gomp_sem_wait, successfully decrements sem to 0.
B calls gomp_set_wait, drops into gomp_sem_wait_slow, sets sem to -1
and blocks.
C calls gomp_set_wait, and similarly blocks.  sem is -1.
A calls gomp_sem_post, drops into gomp_sem_post_slow, sets sem to 1
and wakes one thread, lets say B.
B grabs sem, sets it to 0.
B calls gomp_sem_post, setting sem to 1 but does not wake up C.
With no more semaphore activity, C stays blocked forever.

You might think that adding one to wake count would fix this,
ie. waking one more thread than can successfully get the semaphore,
with the idea that the failing thread will then set sem to -1 to flag
that some threads are waiting.  That doesn't work though.  Add one
more thread to the example above, D, that like C is blocked.  When A
wakes two threads, B and C say, B might get the sem then release it
before C runs.  Then C won't wake up D.