Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1407318064.24324.282.camel@eris.loria.fr>
Date: Wed, 06 Aug 2014 11:41:04 +0200
From: Jens Gustedt <jens.gustedt@...ia.fr>
To: musl@...ts.openwall.com
Subject: Re: Explaining cond var destroy [Re: C threads, v3.0]

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




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.