[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1408002103.4951.88.camel@eris.loria.fr>
Date: Thu, 14 Aug 2014 09:41:43 +0200
From: Jens Gustedt <jens.gustedt@...ia.fr>
To: musl@...ts.openwall.com
Subject: Re: My current understanding of cond var access restrictions
Am Mittwoch, den 13.08.2014, 22:19 -0400 schrieb Rich Felker:
> On Thu, Aug 14, 2014 at 01:20:25AM +0200, Jens Gustedt wrote:
> > But have in mind that all what you say, strongly relies on
> > implementing each of the control structures as one monolithic
> > object. As soon as you split conditions into two parts (one the user
> > space interface, one an internal synchronization structure that is
> > allocated separately) part of the trouble disappears.
>
> The basic idea of your design is reference-counting the object.
> There's no need for dynamic allocation to make this work.
I am not sure. At least for my current design for C threads, the
auxiliary object is unlinked as soon as there is a potential move-over
to use a different mutex. That is as soon that the number of waiters
provably drops to 0. Then the aux object is unlinked and an eventual
new waiter allocates a new one. By that the processing is clearly in
batches, all threads involved in one batch use the same mutex and
these batches don't step on each others feet.
> Simply
> incrementing/decrementing a reference counter in the main object, and
> waiting for it to reach zero in the destroy function, achieves the
> same thing -- but it requires either spinlocks or a FUTEX_WAKE_OP for
> the final decrement-to-zero if there is a destroyer waiting.
Yes, if you don't like spinlocks you'd have to use a futex wait-wake
scheme.
But in the "aux" model, the futex wake can act on an object in the
aux. Only those waiters and wakers from the same batch will ever touch
that aux. So there is no problem to change that to a mutex-like lock
scheme.
> Of course this doesn't work for the unmapping issue with
> process-shared objects, but allocation doesn't work there either.
yes
> > This supposing that the mutex unlock operation and the wait operation
> > are done with two different system calls.
>
> Yes. Linux has no futex operation which both writes and waits except
> possibly priority-inheritance locking, which is definitely not an
> appropriate primitive here.
yes, too bad
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.
