Re: bug in pthread_cond_broadcast

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

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

Am Dienstag, den 12.08.2014, 17:20 -0400 schrieb Rich Felker:
> On Tue, Aug 12, 2014 at 08:18:59PM +0200, Jens Gustedt wrote:
> > so yes, the broadcast operation is synchronized with all other
> > threads, that's the idea of this test
> 
> OK, thanks for clarifying. I'm still trying to understand where the
> error in musl's accounting is happening --

I think these are the decrement operations on _c_waiters and
_c_waiters2 in "unwait". In the case of the test, for pending waiters,
these happen after other threads know that the condition variable is
"released" by the main thread and have already entered the next phase.

> I'd like to find a fix that
> would be acceptable in the 1.0.x branch and make that fix before
> possibly re-doing the cond var implementation (a fix which wouldn't be
> suitable for backporting).

Some thoughts:

Basically, in "unwait" there shouldn't be any reference to c-> .  No
pending thread inside timedwait should ever have to access the
pthread_cond_t, again, it might already heavily used by other threads.

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.

 - verify that all wanted waiters are in, otherwise repeat the requeue
   operation. (this should be a rare event)

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

The only disadvantage that I see with such a procedure is that the
waker is holding _c_lock when going into the futex call. 

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