From owner-freebsd-current Sun Jan 31 07:41:05 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA10970 for freebsd-current-outgoing; Sun, 31 Jan 1999 07:41:05 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ns.tar.com (ns.tar.com [204.95.187.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA10965 for ; Sun, 31 Jan 1999 07:41:01 -0800 (PST) (envelope-from dick@ns.tar.com) Received: (from dick@localhost) by ns.tar.com (8.9.2/8.9.1) id JAA51513; Sun, 31 Jan 1999 09:40:29 -0600 (CST) (envelope-from dick) Date: Sun, 31 Jan 1999 09:40:29 -0600 From: "Richard Seaman, Jr." To: Peter Dufault Cc: John Birrell , current@FreeBSD.ORG, bde@zeta.org.au Subject: Re: more about yield() versus sched_yield() Message-ID: <19990131094029.D29670@tar.com> References: <199901311022.FAA21322@hda.hda.com> <199901311034.VAA01602@cimlogic.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <199901311034.VAA01602@cimlogic.com.au>; from John Birrell on Sun, Jan 31, 1999 at 09:34:45PM +1100 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Jan 31, 1999 at 09:34:45PM +1100, John Birrell wrote: > Peter Dufault wrote: > > > I've got a synch_yield() in kern_synch and a call into it from yield() > > > in kern_thread that duplicates the yield() behavior for the non-RTPRIO, > > > non-sched_yield() condition. synch_yield() also KASSERTS > > > that p == curproc since nothing else makes sense. > > > > While we're discussing yield here's a question. > > > > The difference between yield() and sched_yield() is that yield unconditionally > > yields while sched_yield() won't if you are the highest priority process > > and the only process in your run queue. Does anyone know the > > reuirements on yield() and would it continue to function for us if > > it worked the same as sched_yield()? > > FWIW, the yield syscall is _not_ built into libc, so I doubt there will > be anything that actually uses it. I think you should just keep > sched_yield(). FWIW, there was sample code posted to -current by John Dyson that used the syscall yield, as well as the undocumented (and absent from libc) syscalls thr_sleep and thr_wakeup. The implication of his comments was that he used the code, or something like it, in some production application. As I indicated to you several weeks ago, I think it is possible to have a priority inversion problem in spinlocks that spin on sched_yield. The yield call, as implemented, partly addresses the issue. However, as you commented to me, it does so poorly. If the consensus is to drop or modify SYS_yield, my vote would be to give consideration to changing the call to more correctly address the priority inversion issue. Possibly a yield (pid_t pid) where the pid passed in is the pid of the thread (process) holding a lock. The system could then check the credentials of the pid to see if there is permission (eg. its a kernel thread of the same process) and if so, raise the priority of pid to that of the calling process for one time slice so pid has a chance to execute and free the lock. -- Richard Seaman, Jr. email: dick@tar.com 5182 N. Maple Lane phone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message