Messages in this thread | | | Date | Thu, 12 Jun 2008 00:45:13 +0200 | From | "Leon Woestenberg" <> | Subject | Re: sched_yield() on 2.6.25 |
| |
Hello,
On Wed, Jun 11, 2008 at 5:28 PM, Bodo Eggert <7eggert@gmx.de> wrote: > Peter Zijlstra <a.p.zijlstra@chello.nl> wrote: >> On Mon, 2008-06-09 at 08:37 +0200, Jakub Jozwicki wrote: > >>> From the man sched_yield: >>> >>> A process can relinquish the processor voluntarily without blocking by >>> calling sched_yield(). The process will then be moved to the end of the >>> queue for its static priority and a new process gets to run. >>> >>> and also IEEE/Open Group: >>> http://www.opengroup.org/onlinepubs/000095399/functions/sched_yield.html >> >> Yeah, except that is for Real-Time scheduling classes, SCHED_OTHER >> doesn't have static priority queues. >> >> SCHED_OTHER doesn't have a specified implementation - so relying on it >> to do anything specific is well outside the scope of definition. > > OTOH, it's sane not to schedule exactly the thread which just tried > to say "I can't do any sane work, please run another thread. > That's not the definition of sched_yield(). See the earlier emails, and the quote above.
As the code after sched_yield() has to be executed the thread will be rescheduled soon (or even immediately) anyway.
The users not understanding the limited scope where sched_yield() behaves deterministicly, seem to think that _yield() will yield() AND lower the thread's dynamic priority for SCHED_OTHER. Is downgrading the dynamic priority a behavioral option?
On the other hand, I don't think anything should encourage the use of sched_yield() outside of the rare SCHED_FIFO/RR case.
Regards, -- Leon
| |