[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140817154409.GJ12888@brightrain.aerifal.cx>
Date: Sun, 17 Aug 2014 11:44:09 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: New private cond var design
On Sun, Aug 17, 2014 at 03:44:15PM +0200, Jens Gustedt wrote:
> Hi,
> I definitively like this idea of the list items on the stack.
Do you have a preference which variant? It's not clear to me whether
your comments are in regard to variant 1 or 2 or apply to both.
> Some thoughts:
>
> Threads can leave the list prematurely, so we need a doubly linked list.
Yes, obviously.
> Threads that are inside the wait function can be organized that they hold the mutex,
> this should avoid a lot of race trouble maintaining the list.
If we have one list per 'instance' rather than a single list of all
waiters that haven't yet exited, then yes, the waiters are all using
the mutex and thereby excluding one another from access to the list.
But the signal/broadcast thread(s) still need a way to access the list
and cv object safely...
> Broadcast can be done in O(1) when delegating the wake up to the
> threads on the list one after another. These have to acquire the
> mutex anyhow, one at a time.
Is your thought to have each waiter, after acquiring the mutex in
preparation to return, requeue the next waiter (if any) onto the
mutex? I think this works and should be conforming. And with this
approach there seems to be no reason to prefer having all waiters use
the same futex rather than a futex local to their own stacks, so the
option 2 looks very attractive.
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.
