Re: Resuming work on new semaphore

[Rich Felker <dalias@libc.org>]

On Sun, Apr 05, 2015 at 05:17:35PM +0300, Alexander Monakov wrote:
> In a similar vein, if the caller explicitely kills other waiters before
> invoking sem_post and sem_getvalue, it will also reveal an inconsistency with
> the new implementation: returned value of 0 will look as if sem_post has woken
> some waiters, even though the caller could know for certain that no tasks were
> waiting on the semaphore.

I'm not concerned about async killing (which is something of a broken
usage case anyway; it certainly doesn't work for other sync objects
except robust mutexes) but I am somewhat concerned about other
equivalent cases. For example:

1. Thread A enters sem_wait.
2. Thread B observes thread A in sem_wait via failed sem_trywait.
3. Thread B sends a signal to thread A.
4. Thread A blocks in signal handler waiting for some other event
   under the control of thread B.
5. Thread B calls sem_post.
6. Thread B calls sem_wait and succeeds.
7. Thread B unblocks thread A.
8. Thread A remains blocked on the sem since B consumed the wake.

Note that the same thing happens with the old or new implementation;
the only difference is the _values_ observed. I believe this behavior
is forbidden by the following:

    If the semaphore value resulting from this operation is positive,
    then no threads were blocked waiting for the semaphore to become
    unlocked; the semaphore value is simply incremented.

    If the value of the semaphore resulting from this operation is
    zero, then one of the threads blocked waiting for the semaphore
    shall be allowed to return successfully from its call to
    sem_wait()."

The old (current) implementation wrongly yields a positive value
despite there being waiters. The new implementation wrongly allows
sem_wait to succeed (and steal a wake) when the value is zero.

> Well we can make sem_getvalue return val[0]+val[1] instead... ;)

That just makes the new implementation look like the old one, no? :-)

Rich