Re: Resuming work on new semaphore

[Rich Felker <dalias@libc.org>]

On Fri, Apr 24, 2015 at 06:47:45PM +0300, Alexander Monakov wrote:
> One more thought.  In the original proposal, val[1] was a "wake count".  By
> now we have drifted away a bit from that concept, with val[1] being used not
> only in post/timedwait, but also in trywait/getvalue, trywait explicitely
> performing post-stealing, and getvalue accounting for that.
> 
> So how about we try to stick with the original vision, and say that val[1] is
> strictly for waiters leaving futex wait via non-error path?  The kernel tells
> the poster via the return value of futex_wake whether the wake has caused any
> waiter to resume execution.  The kernel already knows if any waiter was there
> to accept a wake, and lets us know.  Can we somehow use that to implement
> non-stealing wakeups?

This is the famous problem discussed on libc-alpha in regards to
documenting the futex syscall. If you could reliably assume that any
zero return from futex wait syscall resulted from an intentional futex
wake, this kind of protocol would be possible. Unfortunately almost
every existing use of futex wake sends the wake after the memory could
already be reused for something new.

Fixing this is possible with clever use of FUTEX_WAKE_OP, possibly
with a performance hit (but conversely, improving some scheduling
behavior), but you'd need a contract that everything agrees to use
this protocol. Even one piece of code failing to do so would horribly
break code depending on the assumption that "zero means intentional
wake". So I don't think it's practical.

Also there's the issue that the target may not actually be in the
syscall when the wake arrives -- it may be suspended just before it,
or in a signal handler. I'm not sure whether those issues are solvable
or not.

Rich