From owner-freebsd-arch Wed Jan 3 17: 7:31 2001 From owner-freebsd-arch@FreeBSD.ORG Wed Jan 3 17:07:28 2001 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from io.yi.org (cr66388-a.rchrd1.on.wave.home.com [24.114.165.24]) by hub.freebsd.org (Postfix) with ESMTP id 353C437B402 for ; Wed, 3 Jan 2001 17:07:28 -0800 (PST) Received: from io.yi.org (localhost.gvcl1.bc.wave.home.com [127.0.0.1]) by io.yi.org (Postfix) with ESMTP id 287D0BA7D; Wed, 3 Jan 2001 20:02:41 -0500 (EST) X-Mailer: exmh version 2.1.1 10/15/1999 To: Daniel Eischen Cc: Jake Burkholder , Jason Evans , arch@FreeBSD.ORG, jake@io.yi.org Subject: Re: Condition variable patch for review In-Reply-To: Message from Daniel Eischen of "Wed, 03 Jan 2001 18:47:30 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 03 Jan 2001 20:02:41 -0500 From: Jake Burkholder Message-Id: <20010104010241.287D0BA7D@io.yi.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Wed, 3 Jan 2001, Jake Burkholder wrote: > > > On 29 Dec 2000, Jason Evans wrote: > > > > There is a patch that implements condition variables (mostly written by > > > > Jake Burkholder) at: > > > > > > > > http://people.freebsd.org/~jasone/diffs/condvar.diff > > > > > > Comments: > > > > > > Get rid of the 'pri' parameter. Why is it needed, and if so, > > > is it needed in the common case? Look for other ways to accomplish > > > what you need without dirtying the CV interface and making it > > > non-standard. This is the same comment I have about the mutex > > > interface and needing to pass the mutex type to every operation. > > > Please, let's see this eliminated before 5.0-release, otherwise > > > we are stuck with it as an API. > > > > I'm not sure that it can be removed if condition variables are > > to be used where sleep is now. Maybe it can if the re-write of the > > kernel scheduler to support kses amounts to more than s/proc/kse/. > > What it does is give processes a priority jolt when they wake up, > > so they get to run Real Soon. Look at the priority values that are > > passed in to tsleep for an example. > > The priorities in tsleep() are the soft priorities that should now > go away. Each thread has its own priority and we also have priority > inheritence mutexes. I assume interrupt threads run at higher > priority than other threads/processes. What additional "boost" > is needed? It depends on how urgent the thing that the process is waiting for is. Also, process priority degrades over time. > > Look at Solaris kernel condition variables - there is no priority > as a parameter and they also transitioned from splXXX/tsleep. > They do have ddi_iblock_cookies (ddi_get_iblock_cookie and > ddi_get_soft_iblock_cookie) that can be associated with kernel > mutexes, though. I suppose this is how they can "boost" the > priority of threads that own/wait on mutexes that have been > init'd with these cookies. I'd rather see us do something > along this line if we have to. I've read the headers and the man pages... > > > I don't care either way as long as it works. > > > > > > Identify which functions are part of our kernel API. I would > > > think that cv_waitq_empty and cv_waitq_remove would not be > > > part of this interface. I assume cv_waitq_remove will eventually > > > take a struct thread (or something) instead of a struct proc. > > > I'd rather see this as a macro since it's usage should be > > > limited. > > > > It parallels unsleep. I don't see any reason to make it a macro. > > It should only be used in one place, in setrunnable when the process > > that's passed in is on a condition variable queue. > > And if it's only used in one place, is it something that we want > device drivers to use? Let's keep functions like this out of our > advertised kernel API, or at least document those that shouldn't > be used by ABI compliant drivers/modules. BTW, I don't see unsleep() > in sleep(9) nor in . proc.h:void unsleep __P((struct proc *)); > > -- > Dan Eischen > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message