Date: Wed, 03 Jan 2001 20:02:41 -0500 From: Jake Burkholder <jburkhol@home.com> To: Daniel Eischen <eischen@vigrid.com> Cc: Jake Burkholder <jburkhol@home.com>, Jason Evans <jasone@canonware.com>, arch@FreeBSD.ORG, jake@io.yi.org Subject: Re: Condition variable patch for review Message-ID: <20010104010241.287D0BA7D@io.yi.org> In-Reply-To: Message from Daniel Eischen <eischen@vigrid.com> of "Wed, 03 Jan 2001 18:47:30 EST." <Pine.SUN.3.91.1010103180706.28466A-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 <sys/systm.h>. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010104010241.287D0BA7D>