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: d...@tar.com 5182 N. Maple Lane phone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
