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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
