[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 6 Aug 2014 06:03:35 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Explaining cond var destroy [Re: C threads, v3.0]
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
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.
