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: unassig...@gcc.gnu.org ReportedBy: amo...@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.