![]() | |||||||||||||
Messages in this thread |
Howard Chu wrote: > Nick Piggin wrote: > >> Howard Chu wrote: >> >>> 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. > > > The fact that sched_yield came originally from the realtime extensions > is just a historical artifact. There was a pthread_yield() function > specifically for threads and it was merged with sched_yield(). Today > sched_yield() is a core part of the basic Threads specification, > independent of the realtime extensions. The fact that it is defined > solely in the language of the realtime priorities is an obvious flaw in > the spec, since the function itself exists independently of realtime > priorities. The objection I raised with the Open Group specifically > addresses this flaw. > Either way, it by no means says anything about yielding to other threads in the process but nobody else. Where did you get that from? >> Linux's SCHED_OTHER behaviour is arguably the best interpretation, >> considering SCHED_OTHER is defined to have a single priority level. > > > It appears that you just read the spec and blindly followed it without > thinking about what it really said and failed to say. The best No, a spec is something that is written unambiguously, and generally the wording leads me to believe they attempted to make it so (it definitely isn't perfect - your mutex unlock example is one that could be interpreted either way). If they failed to say something that should be there then the spec needs to be corrected -- however in this case I don't think you've shown what's missing. And actually your reading things into the spec that "they failed to say" is wrong I believe (in the above sched_yield example). > interpretation would come from saying "hey, this spec is only defined > for realtime behavior, WTF is it supposed to do for the default > non-realtime case?" and getting a clear definition in the spec. > However they do not omit to say that. They quite explicitly say that SCHED_OTHER is considered a single priority class in relation to its interactions with other realtime classes, and is otherwise free to be implemented in any way. I can't see how you still have a problem with that... -- 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2006-01-26 17:05 [from the cache] ©2003-2008 | |||||||||||||