Howard Chu wrote:
Nick Piggin wrote:
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
Yes, and even SCHED_OTHER in Linux attempts to do this as part of
the principle of least surprise. That it doesn't _exactly_ match
what you want it to do just means you need to be using something
else.
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
No I don't think so. POSIX 1.b where sched_yield is defined are the
realtime extensions, are they not?
sched_yield explicitly makes reference to the realtime priority system
of thread lists does it not? It is pretty clear that it is used for
realtime processes to deterministically give up their timeslices to
others of the same priority level.
Linux's SCHED_OTHER behaviour is arguably the best interpretation,
considering SCHED_OTHER is defined to have a single priority level.
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
It yields to all other SCHED_OTHER processes (which are all on the
same thread priority list) and not to any other processes of higher
realtime priority.
scheduling behavior they would have used fork().
It so happens that processes and threads use the same scheduling
policy in Linux. Is that forbidden somewhere?
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.
--
Send instant messages to your online friends http://au.messenger.yahoo.com
-
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]
