Re: My current understanding of cond var access restrictions

[Jens Gustedt <jens.gustedt@inria.fr>]

[-- Attachment #1: Type: text/plain, Size: 2700 bytes --]

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 ::



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]