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: [email protected]
ReportedBy: [email protected]
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.
