Date: Wed, 17 Jan 2001 12:10:51 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: Matt Dillon <dillon@earth.backplane.com> Cc: arch@FreeBSD.ORG Subject: Re: HEADS-UP: await/asleep removal imminent Message-ID: <20010117121051.Z7240@fw.wintelcom.net> In-Reply-To: <200101171958.f0HJwv649221@earth.backplane.com>; from dillon@earth.backplane.com on Wed, Jan 17, 2001 at 11:58:57AM -0800 References: <200101171138.MAA11834@freebsd.dk> <ybug0iixiee.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net> <20010117092109.O7240@fw.wintelcom.net> <20010117100516.Q7240@fw.wintelcom.net> <200101171907.f0HJ7Qe48680@earth.backplane.com> <20010117112850.X7240@fw.wintelcom.net> <200101171958.f0HJwv649221@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Matt Dillon <dillon@earth.backplane.com> [010117 11:59] wrote: > > :This is confusing: > : > :> > :> Revamp asleep/await to be based on state variables rather then > :> tsleep's traditionaln 'fake' addresses. Rather then > :> have a traditional sleep/wakeup we instead have a state variable that > :> asleep/await operate on. For example lets say we have a memory allocator. > :> When the memory allocator finds it would block, it utilizes a global > :> state structure representing the blockage and clears the state > :> (blah.state = 0;). Then it calls asleep(&blah). asleep simply stores > :> the pointer to &blah in the process structure, it does not try to queue > :> it or do anything else. Thus no locking or mutexes or interrupt > :> disablement is required *at all*. The routine is entirely passive and > :> safe to call from anywhere. > : > :It's not queued _anywhere_? > > Right. Not queued anywhere... the await() (or tsleep or whatever) > code would check for the existance of the pointer in the proc > structure at the time the process tries to go to sleep. > > This is why you need a condition variable... because there is no > way for an asynchronous event to 'wakeup' the process before it has > tried to go to sleep for real the process needs some way to detect > that the event has occured, hence the necessity of a condition > variable. > > The traditional tsleep/wakeup code has *NO* persistent state associated > with it, which means the process is required to place itself on the > sleep queue atomically in order to avoid the event occuring between the > resource allocation failure (or whatever) and the tsleep() call. I think you guys may be confused, I think you're mistaking our conditional variables with counting semaphores which act as sort of turnstiles(sp?) where you put in N tokens and only N procs can pass through them before blocking. The conditional variables as implemented in FreeBSD seem to only wake up something sleeping on them, they don't have the abilities you're looking for. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010117121051.Z7240>