Date: Sun, 31 Jan 1999 09:40:29 -0600 From: "Richard Seaman, Jr." <dick@tar.com> To: Peter Dufault <dufault@hda.com> Cc: John Birrell <jb@cimlogic.com.au>, current@FreeBSD.ORG, bde@zeta.org.au Subject: Re: more about yield() versus sched_yield() Message-ID: <19990131094029.D29670@tar.com> In-Reply-To: <199901311034.VAA01602@cimlogic.com.au>; from John Birrell on Sun, Jan 31, 1999 at 09:34:45PM %2B1100 References: <199901311022.FAA21322@hda.hda.com> <199901311034.VAA01602@cimlogic.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990131094029.D29670>