Re: Resuming work on new semaphore

[Alexander Monakov <amonakov@ispras.ru>]

On Thu, 23 Apr 2015, Rich Felker wrote:
> Perhaps this can be patched up by saturating sem_getvalue's result? In
> the case where the overflow happens it's transient, right? I think
> that means discounting the overflow would be valid. But I'll need to
> think about it more...

Hm, can't agree here.  This whole line of discussion stems from attempt to
align timedwait/trywait/getvalue behavior in light of dead waiters, which are
indistinguishable from preempted waiters.  If "it's transient" claim can be
made, it also can be used as a reason not to modify getvalue to look at val[1].

> With that said, my inclination right now is that we should hold off on
> trying to commit the new semaphore for this release cycle. I've been
> aiming for this month and just about everything else is in order for
> release, but the semaphore rabbit-hole keeps going deeper and I think
> we need to work through this properly. I hope that's not too much of a
> disappointment.

Ack; thankfully I don't feel disappointment in this case, this discussion has
been quite entertaining.  When I proposed my modification I felt it was very
intuitive.  What I did not grasp back then is that the definition of a waiter
is not solid.

How do you interpret the following?

1. Semaphore initialized to 0. There's only one thread.
2. alarm(1)
3. sem_wait()
... (in SIGALRM handler)
    4. sem_post()
    5. sem_getvalue()

May getvalue be 0 here?  At step 4, can the thread possibly "be a waiter"
on the semaphore?

Thanks.
Alexander