From owner-freebsd-arch Wed Jan 3 15: 0:52 2001 From owner-freebsd-arch@FreeBSD.ORG Wed Jan 3 15:00:49 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 27F6437B400 for ; Wed, 3 Jan 2001 15:00:49 -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 03B1EBA7D; Wed, 3 Jan 2001 17:56:03 -0500 (EST) X-Mailer: exmh version 2.1.1 10/15/1999 To: Daniel Eischen Cc: Jason Evans , arch@FreeBSD.ORG Subject: Re: Condition variable patch for review In-Reply-To: Message from Daniel Eischen of "Fri, 29 Dec 2000 14:58:11 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 03 Jan 2001 17:56:02 -0500 From: Jake Burkholder Message-Id: <20010103225603.03B1EBA7D@io.yi.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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. 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. > > I prefer cv_timedwait over cv_twait... > > Other than that, I am happy that we finally have condition > variables :-) > > -- > 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