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

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

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

Am Mittwoch, den 06.08.2014, 10:43 +0200 schrieb Jens Gustedt:
> Am Dienstag, den 05.08.2014, 23:52 -0400 schrieb Rich Felker:
> > 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.
> 
> 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.

After digging a bit deeper I think I would favor a solution where no
waiter has to touch the condition object at all when coming back from
the wait. Currently this is not the case, in the contrary it reads
_c_seq and then does heavy maintenance in the unwait() call.

The return from a wait should just run into the the call to
pthread_mutex_lock, which would be save since the call has access to
that mutex from its arguments. All the bookkeeping should be done by
pthread_cond_signal and pthread_cond_broadcast before they wake up
anybody.

I am not sure that this would easily be possible with the current
implementation, but I think that this would be ideal.

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