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.