Resuming work on new semaphore

[Rich Felker <dalias@libc.org>]

I have Alexander Monakov's new semaphore design on the agenda for this
release cycle (1.1.9). If I remember correctly, we were looking at
some issues in the last posted version with barriers and how to write
the code in a way that's both clean and avoids compiler stupidity.

One other thing I've been thinking about is how the current and new
semaphore designs differ when a waiter on a process-shared semaphore
is asynchronously killed (while waiting or during acceptance of the
post).

With the current design:

If just waiting, the waiters count remains permanently elevated (and
will eventually overflow if this happens billions of times), and any
posts will make the value positive so that another waiter can take the
post.

If accepting (at least one atomic operation on the sem already
performed) then the waiters count is left valid and either a post is
consumed or left for another waiter to take.

With the new design:

If just waiting, the negative semaphore value persists after the
waiter is killed. Subsequent posts will produce a wake for a waiter
that doesn't exist, and will thereby allow future waiters that arrive
when the semaphore value is zero to proceed immediately (leaving the
value negative) by consuming this wake. There are usage patterns where
trywait would never succeed again, but wait would succeed trivially.

If accepting, the post is consumed. Accepting only involves one atomic
operation so there is no other possibility.

It seems to me the behavior for async-kill-while-waiting is somewhat
worse with the new design, but this isn't really a usage pattern that
should have been considered "supported" before, anyway. If there are
ideas to make it better, we could explore them, but I don't think it's
a show-stopper in any case.

Rich