From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: Explaining cond var destroy [Re: [musl] C threads, v3.0]
Date: Wed, 6 Aug 2014 06:03:35 -0400 [thread overview]
Message-ID: <20140806100335.GV1674@brightrain.aerifal.cx> (raw)
In-Reply-To: <1407318064.24324.282.camel@eris.loria.fr>
On Wed, Aug 06, 2014 at 11:41:04AM +0200, Jens Gustedt wrote:
> Am Mittwoch, den 06.08.2014, 10:43 +0200 schrieb Jens Gustedt:
> > Am Dienstag, den 05.08.2014, 23:52 -0400 schrieb Rich Felker:
> > > If you think this is a bad idea, I'd be willing to hear alternate
> > > ideas. I'm not really happy with the cond var implementation (if
> > > nothing else, the sequence number thing is an ugly hack and not 100%
> > > robust, I think) and at some point I'd like to redesign it.
> >
> > I am not sure about how to deal with this. The idea that destroy may
> > be blocking or even be doing a context switch to the kernel came as a
> > surprise to me. Maybe I would be happier if _c_destroy would be used
> > as a usage count and destroy would just spinlock on that would be more
> > straight.
>
> After digging a bit deeper I think I would favor a solution where no
> waiter has to touch the condition object at all when coming back from
> the wait. Currently this is not the case, in the contrary it reads
> _c_seq and then does heavy maintenance in the unwait() call.
>
> The return from a wait should just run into the the call to
> pthread_mutex_lock, which would be save since the call has access to
> that mutex from its arguments. All the bookkeeping should be done by
> pthread_cond_signal and pthread_cond_broadcast before they wake up
> anybody.
>
> I am not sure that this would easily be possible with the current
> implementation, but I think that this would be ideal.
Yes, that would be my ideal too, but I'm not sure it's possible. Well,
not with an efficient implementation anyway. There's a trivial
implementation where pthread_cond_timedwait is basically just:
a_store(&c->_tid, self->tid);
pthread_mutex_unlock(mtx);
__timedwait(&c->tid, self->tid, ts, clock, ts, cleanup, mtx, 0);
pthread_mutex_lock(mtx);
This makes signal and broadcast operations utterly trivial (just set
c->tid to 0 and call __wake with 1 or INT_MAX as the argument), but it
has lots of spurious wakes under contention, I think, and perhaps
other serious drawbacks too. If I remember correctly, musl's original
implementation looked something like the above, but I was also having
a hard time figuring out how to work requeue-to-mutex (which makes a
big deal to performance on big broadcasts) into it.
One idea I've been playing with is possibly eliminating most or all
use of waiter counts in musl and using a pure potential-waiters-flag
approach. That's a whole separate topic I should start a thread on,
but to be brief, it's motivated by some pathological behavior of
waiter counts under rapid lock/unlock by the same thread where a
useless futex wake happens after each unlock if the waiter has not yet
gotten a chance to run. If eliminating waiter counts would make it
easier to do a good cond var implementation that would be another
reason to consider it.
Rich
next prev parent reply other threads:[~2014-08-06 10:03 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-04 9:30 C threads, v3.0 Jens Gustedt
2014-08-04 9:33 ` Jens Gustedt
2014-08-04 14:50 ` Rich Felker
2014-08-04 16:48 ` Jens Gustedt
2014-08-04 17:06 ` Rich Felker
2014-08-04 22:16 ` Jens Gustedt
2014-08-04 22:36 ` Rich Felker
2014-08-06 3:52 ` Explaining cond var destroy [Re: [musl] C threads, v3.0] Rich Felker
2014-08-06 8:43 ` Jens Gustedt
2014-08-06 9:41 ` Jens Gustedt
2014-08-06 10:03 ` Rich Felker [this message]
2014-08-06 10:32 ` Jens Gustedt
2014-08-06 16:15 ` Rich Felker
2014-08-06 16:56 ` Jens Gustedt
2014-08-06 17:32 ` Rich Felker
2014-08-06 20:55 ` Jens Gustedt
2014-08-06 22:04 ` Rich Felker
2014-08-06 22:43 ` Jens Gustedt
2014-08-06 23:15 ` Rich Felker
2014-08-07 7:50 ` Jens Gustedt
2014-08-07 10:52 ` Szabolcs Nagy
2014-08-07 11:03 ` Jens Gustedt
2014-08-07 16:13 ` Rich Felker
2014-08-07 16:47 ` Jens Gustedt
2014-08-07 17:25 ` Rich Felker
2014-08-08 9:20 ` Jens Gustedt
2014-08-08 16:53 ` Rich Felker
2014-08-08 19:14 ` Rich Felker
2014-08-08 20:48 ` Rich Felker
2014-08-09 6:47 ` Jens Gustedt
2014-08-12 2:50 ` Rich Felker
2014-08-12 7:04 ` Jens Gustedt
2014-08-12 16:01 ` Rich Felker
2014-08-12 19:09 ` Jens Gustedt
2014-08-12 21:18 ` Rich Felker
2014-08-13 6:43 ` Jens Gustedt
2014-08-13 7:19 ` Jens Gustedt
2014-08-06 9:50 ` Rich Felker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140806100335.GV1674@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).