[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 15 Aug 2014 16:28:13 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: New private cond var design
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
