[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140827200756.GS12888@brightrain.aerifal.cx>
Date: Wed, 27 Aug 2014 16:07:56 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH 2/2] avoid taking _c_lock if we know it isn't
necessary
On Wed, Aug 27, 2014 at 11:57:47AM +0200, Jens Gustedt wrote:
> + /* Since this leaving waiter might not have held the _c_lock, the following */
> + /* __wake might be issued when the signaler is still inside its CS. */
> + /* But if so, this avoids a __wait of the signaler, which more important. */
> + /* This should not target any spurious wake up in any other thread: */
> + /* ref is on the stack of the signaler, and that signaler is still alive. */
> if (ref) {
> if (a_fetch_add(ref, -1)==1)
> __wake(ref, 1, 1);
Can't you avoid that with the design I suggested, having the signaler
use an extra ref count on itself, which it decrements right before
waiting?
Aside from that, based on my reading so far, these patches look like
they should work correctly. But since we both want to get C11 threads
done, let's put them aside for now (pending some testing for
measurable benefits). I also have some other potential changes to this
code based on my latest comments to:
http://austingroupbugs.net/view.php?id=609
regarding things they seem to deem as requirements, and which musl
does not satisfy, that are specified in non-normative text. So there's
likely to be more cond var work to do before the release still...
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.
