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

From: Nick Piggin
Date: Thu Jan 26 2006 - 10:49:49 EST


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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/