[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 14 Aug 2014 10:00:04 +0200
From: Jens Gustedt <jens.gustedt@...ia.fr>
To: musl@...ts.openwall.com
Subject: Re: My current understanding of cond var access restrictions
Am Donnerstag, den 14.08.2014, 02:10 -0400 schrieb Rich Felker:
> I think I have an informal proof sketch that this is necessary unless
> we abandon requeue:
> ...
> With that in mind, I'd like to look for ways we can fix the bogus
> waiter accounting for the mutex that seems to be the source of the bug
> you found. One "obvious" (but maybe bad/wrong?) solution would be to
> put the count on the mutex at the time of waiting (rather than moving
> it there as part of broadcast), so that decrementing the mutex waiter
> count is always the right thing to do in unwait.
sounds like a good idea, at least for correctness
> Of course this
> possibly results in lots of spurious futex wakes to the mutex (every
> time it's unlocked while there are waiters on the cv, which could be a
> lot).
I we'd be more careful in not spreading too much wakes where we
shouldn't, there would perhaps not be "a lot" of such wakeups.
> It would be nice if we had a separate field in the mutex (rather
> than in the cv, as it is now) to store these on, and only move them to
> the active waiters count at broadcast time, but I don't see any way to
> get additional space in the mutex structure for this -- it's full.
I thought of such designs, too, but one major problem (besides the
space) with it is that a mutex can be used by several cv at a time.
> > > 5. When can [timed]wait safely access the cv?
> > >
> > > Only before unlocking the mutex, unless the implementation
> > > synchronizes with possible signaling threads, or with destruction (and
> > > possibly unmapping). Otherwise, per the above, it's possible that a
> > > signaling thread destroys the cv.
> >
> > so again this suggests an internal lock on the cv that would be used
> > to synchronize between waiters and wakers?
>
> This argument applies even to process-shared cv's, and for them, no
> allocation is possible,
at least difficult, for sure
this would need support to allocate some object in the kernel and to
use that object shared between processes :(
> and I don't see a really good way to solve the
> unmapping issue -- I think broadcast/signal would have to block
> unmapping, and the last waiter to wake up would have to unblock it.
> Maybe that's the right solution?
probably, as I said, I don't have the right feeling for the mapping
issues, yet.
Jens
--
:: INRIA Nancy Grand Est ::: AlGorille ::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536 ::
:: :::::::::::::::::::::: gsm France : +33 651400183 ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)
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.
