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

From: Nick Piggin
Date: Thu Jan 26 2006 - 03:53:09 EST


Howard Chu wrote:
Lee Revell wrote:

On Wed, 2006-01-25 at 10:26 -0800, Howard Chu wrote:


The SUSv3 text seems pretty clear. It says "WHEN
pthread_mutex_unlock() is called, ... the scheduling policy SHALL decide ..." It doesn't say MAY, and it doesn't say "some undefined time after the call."


This does NOT require pthread_mutex_unlock() to cause the scheduler to
immediately pick a new runnable process. It only says it's up the the
scheduling POLICY what to do. The policy could be "let the unlocking
thread finish its timeslice then reschedule".


This is obviously some very old ground.

http://groups.google.com/groups?threadm=etai7.108188%24B37.2381726%40news1.rdc1.bc.home.com


Kaz's post clearly interprets the POSIX spec differently from you. The policy can decide *which of the waiting threads* gets the mutex, but the releasing thread is totally out of the picture. For good or bad, the current pthread_mutex_unlock() is not POSIX-compliant. Now then, if we're forced to live with that, for efficiency's sake, that's OK, assuming that valid workarounds exist, such as inserting a sched_yield() after the unlock.

http://groups.google.com/group/comp.programming.threads/msg/16c01eac398a1139?hl=en&;


But then we have to deal with you folks' bizarre notion that sched_yield() can legitimately be a no-op, which also defies the POSIX spec. Again, in SUSv3 "The /sched_yield/() function shall force the running thread to relinquish the processor until it again becomes the head of its thread list. It takes no arguments." There is no language

How many times have we been over this? What do you think the "head of
its thread list" might mean?

here saying "sched_yield *may* do nothing at all." There are of course

There is language saying SCHED_OTHER is arbitrary, including how the
thread list is implemented and how a task might become on the head of
it.

They obviously don't need to redefine exactly what sched_yield may do
under each scheduling policy, do they?

--
SUSE Labs, Novell Inc.
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/