Re: [PATCH] Fix race between sem_post and semaphore destruction [BZ #12674]

[Rich Felker <dalias at libc dot org>]

On Wed, May 21, 2014 at 04:37:11PM +0530, Siddhesh Poyarekar wrote:
> Rich used this condition as a primary check and the waiter count as a
> secondary check, but I think the secondary check is not required in
> glibc.

I think the case I had in mind goes like this:

1. Thread A and B are waiting, val is -1.
2. Thread C posts the semaphore and wakes up thread A, val is now 0.
3. The semaphore gets posted again, but with no indication there's a
   waiter, thread B never wakes up.

You cannot modify sem_post to set the value to -1 rather than 0 if
there's a waiter, because of two issues; one is fundamental and the
other is merely a performance concern:

1. Multiple sem_post calls before the waiters wake up have to
   accumulate the semaphore value increments. You might could satisfy
   this using a flag bit instead of the value -1, but it's ugly.

2. There's no way for sem_post to know if there's another remaining
   waiter. This is because it cannot inspect the waiter count after
   modifying the value -- that's the exact bug you're trying to fix.
   So it would have to always set the waiter indicator, resulting in
   every subsequent sem_post call generating futex syscalls.

It I'm missing something obvious, let me know, but I don't think your
approach works. FWIW, I haven't RTFP'd; I'm just basing this response
on your email text.

Rich