Re: pthread_mutex_unlock (was Re: sched_yield() makes OpenLDAP slow)

[Nick Piggin <nickpiggin@yahoo.com.au>]

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/