Messages in this thread | | | Date | Fri, 27 Jan 2006 02:51:19 +1100 | From | Nick Piggin <> | Subject | Re: pthread_mutex_unlock (was Re: sched_yield() makes OpenLDAP slow) |
| |
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/
| |