lkml.org 
[lkml]   [2006]   [Jan]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2006-01-26 18:05    [W:0.132 / U:0.540 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site