Nick Piggin wrote:
Howard Chu wrote:
But then we have to deal with you folks' bizarre notion that
sched_yield() can legitimately be a no-op, which also defies the
POSIX spec. Again, in SUSv3 "The /sched_yield/() function shall force
the running thread to relinquish the processor until it again becomes
the head of its thread list. It takes no arguments." There is no
language
How many times have we been over this? What do you think the "head of
its thread list" might mean?
here saying "sched_yield *may* do nothing at all." There are of course
There is language saying SCHED_OTHER is arbitrary, including how the
thread list is implemented and how a task might become on the head of
it.
They obviously don't need to redefine exactly what sched_yield may do
under each scheduling policy, do they?
As Dave Butenhof says so often, threading is a cooperative programming
model, not a competitive one. The sched_yield function exists for a
specific purpose, to let one thread decide to allow some other thread to
run. No matter what the scheduling policy, or even if there is no
scheduling policy at all, the expectation is that the current thread
will not continue to run unless there are no other runnable threads in
the same process. The other important point here is that the yielding
thread is only cooperating with other threads in its process. The 2.6
kernel behavior effectively causes the entire process to give up its
time slice, since the yielding thread has to wait for other processes in
the system before it can run again. Again, if folks wanted process
scheduling behavior they would have used fork().
By the way, I've already raised an objection with the Open Group asking
for more clarification here.
http://www.opengroup.org/austin/aardvark/latest/xshbug2.txt request
number 120.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
