[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1407913256.4951.16.camel@eris.loria.fr>
Date: Wed, 13 Aug 2014 09:00:56 +0200
From: Jens Gustedt <jens.gustedt@...ia.fr>
To: musl@...ts.openwall.com
Subject: Re: bug in pthread_cond_broadcast
Am Dienstag, den 12.08.2014, 20:30 -0400 schrieb Rich Felker:
> On Wed, Aug 13, 2014 at 12:50:19AM +0200, Jens Gustedt wrote:
> > The signalling or broacasting thread (waker) should do most of the
> > bookkeeping on the waiters counts. This might be done by
> >
> > - lock _c_lock
> >
> > - if there are no waiters, unlock _c_lock and quit
> >
> > - requeue the wanted number of threads (1 or everybody) from the cnd
> > to the mtx. requeue tells us how many threads have been requeued,
> > and this lets us deduce the number of threads that have been woken
> > up.
>
> If you requeue here, where does any wake happen?
>
> > - verify that all wanted waiters are in, otherwise repeat the requeue
> > operation. (this should be a rare event)
>
> This step is not possible. One or more waiters could be in signal
> handlers which interrupted the wait,
yes, but only one waiter at the time can be in the initial phase of
the wait, waiters always hold the mutex in question. So the waiters
you are talking about are basically the ones that already released the
mutex and are going into the futex-wait. There should be no signal
handler waiting for an event coming from such a thread.
So basically you can assume that waiters have done their part of the
bookkeeping when you are in that situation.
> in which case the futex wait will
> not resume until the signal handler returns. Such a retry loop could
> run forever (e.g. if the signal handler is waiting for an event that
> will only be performed by the [cond-var-]signaling thread after the
> operation finishes).
>
> > - do the bookkeeping: update the cond-waiters count and add the right
> > amount to the mtx-waiters
> >
> > - unlock _c_lock
> >
> > On the waiter side, you'd have to distinguish a successful wakeup by a
> > waker from a spurious wakeup. Only for the later the waiter has to do
> > the bookkeeping. This can only happen as long as the waker is in the
> > "requeue" loop.
>
> I don't understand what you mean.
I mean that a successful wakeup can be determined by the return value
from the system call. If it is such a regular wakeup, the wokenup
thread has nothing to do. Only the special cases of other returns from
the futex wait have to be considered.
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.
