Re: Explaining cond var destroy [Re: [musl] C threads, v3.0]

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

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

Am Dienstag, den 05.08.2014, 23:52 -0400 schrieb Rich Felker:
> On Mon, Aug 04, 2014 at 11:30:03AM +0200, Jens Gustedt wrote:
> > +/* The behavior of cnd_destroy is undefined if cnd is still in
> > +   use. The choice for pthread_cond_destroy in that situation is to
> > +   wake up all users before destroying. I am not sure that we should
> > +   do it like that here, too. Alternatives would be:
> > +   - complain by using perror or equivalent
> > +   - assert that there is no waiter
> > +   - abort when there is a waiter
> > +   - do nothing
> > +   */
> 
> The above comment is incorrect; I'll try to explain. At least for
> POSIX cond vars, per POSIX, at least one thread that has called
> pthread_cond_[timed]wait ceases to be a waiter as soon as
> pthread_cond_signal is called, and all threads which have called
> pthread_cond_[timed]wait ceast to be waiters as soon as
> pthread_cond_broadcast is called. This means that, if a thread calling
> pthread_cond_signal or pthread_cond_broadcast has updated the
> predicate such that no threads will retry pthread_cond_[timed]wait or
> remain as waiters, it may IMMEDIATELY call pthread_cond_destroy
> without violating the constraint that pthread_cond_destroy can only be
> called when there are no waiters.
> 
> Since waiters have additional work to do on the memory associated with
> the pthread_cond_t object after the futex wait completes, and since we
> do not want to force them to wake and finish this work as part of
> pthread_cond_signal/broadcast (this would be expensive on every
> signal), I've put the code to finish waiting for the waiters to wake
> up in pthread_cond_destroy.

ok, I now understand the motivation behind that and will withdraw or
amend that comment.

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

As far as I can see the _c_destroy flag is used for no other purpose
than this synchronization between the destroying thread and potential
latecomers.

Technically the real problem is not pthread_cond_destroy (or
cnd_destroy). This could just be a noop as it is for mutexes. Using a
condition after it is destroyed is UB in terms of the standards, but
nothing hinders us to define a behavior for the specific
implementation of musl.

It is the fact that the thread that calls destroy() might also
deallocate the object directly after, and that the latecomers then
crash because we removed their object under their feet. So this
effectively introduces a deallocation barrier, which is nice, but
clearly an extension.

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.

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