Date: Wed, 3 Jan 2001 18:47:30 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: Jake Burkholder <jburkhol@home.com> Cc: Jason Evans <jasone@canonware.com>, arch@FreeBSD.ORG Subject: Re: Condition variable patch for review Message-ID: <Pine.SUN.3.91.1010103180706.28466A-100000@pcnet1.pcnet.com> In-Reply-To: <20010103225603.03B1EBA7D@io.yi.org>
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? 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 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>. -- Dan Eischen 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?Pine.SUN.3.91.1010103180706.28466A-100000>