Re: New private cond var design

[Rich Felker <dalias@libc.org>]

On Fri, Aug 15, 2014 at 03:35:36PM -0400, Rich Felker wrote:
> The list also allows us to eliminate the sequence number wrapping
> issue (sadly, only for private, non-process-shared cv's, since
> process-shared can't use process-local memory like this) in one of two
> ways:
> 
> Option 1: If the list elements store the sequence number their waiter
> is waiting on, the signal/broadcast operations can choose a new
> sequence number distinct from that of all waiters.

I don't think this actually works to avoid the sequence number issue,
at least not as-described above, since the sequence number still has
to remain unique even once there's a new instance. If we keep a linked
list that's not instance-specific but covers all instances, though, we
could use it to avoid sequence number reuse, but then some (light, I
think) extra accounting is needed to mark what part of the list is
from previous instances.

> Option 2: Each waiter can wait on a separate futex on its own stack,
> so that sequence numbers are totally unneeded. This eliminates all
> spurious wakes; signal can precisely control exactly which waiter
> wakes (e.g. choosing the oldest), thereby waking only one waiter.
> Broadcast then becomes much more expensive: the broadcasting thread
> has to make one requeue syscall per waiter. But this still might be a
> good design.

I think this design is more elegant, and probably performs better in
the case where only signal is used since spurious wakes are avoided
totally, but somewhat worse when broadcasts are being used.

Rich