Date: Wed, 3 Jan 2001 20:39:15 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: Jake Burkholder <jburkhol@home.com> Cc: Jason Evans <jasone@canonware.com>, arch@FreeBSD.ORG, jake@io.yi.org Subject: Re: Condition variable patch for review Message-ID: <Pine.SUN.3.91.1010103201431.15319B-100000@pcnet1.pcnet.com> In-Reply-To: <20010104010241.287D0BA7D@io.yi.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 3 Jan 2001, Jake Burkholder wrote: > > 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. For time-sharing yes. So let it. The wakeup from cv_wait and friends is also suppose to take the mutex again. If there is any priority boost needed, let it be inherent in the mutex. If you own the mutex, you inherit its priority. When you perform the cv_wait() and atomically release the mutex, don't give up the inherited priority. You *will* wake up again with the mutex regardless of whether you've been signaled or not (in the case of timedwaits or a process signal). In lieu of having something like Solaris iblock cookies, I suppose you could init the mutex with the priority that you intend on using in the cv_wait() functions. You can sneek a peek at the mutex priority inside cv_wait if necessary since the mutex is a parameter. > > > 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 *)); Right, but my point was that it's not an API that kernel developers should use; othewise it would be in the man page alongside tsleep and friends :-) -- 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.1010103201431.15319B-100000>