David Schwartz wrote:
Third, there's the ambiguity of the standard. It says the "sceduling
policy" shall decide, not that the scheduler shall decide. If
the policy is
to make a conditional or delayed decision, that is still perfectly valid
policy. "Whichever thread requests it first" is a valid
scheduler policy.
I am not debating what the policy can decide. Merely the set of choices
from which it may decide.
Which is a restriction not found in the standard. A "policy" is a way of
deciding, not a decision. Scheduling policy can be to let whoever asks first
get it.
If we just went with "whoever asks first" then clearly one of the
blocked threads asked before the unlocker made its new request. You're
arguing for my point, then.
Other ambiguities aside, one thing is clear - a decision is triggered by
the unlock. What you seem to be arguing is the equivalent of saying that
the decision is made based on the next lock operation. The spec doesn't
say that mutex_lock is to behave this way. Why do you suppose that is?
Perhaps you should raise this question with the Open Group.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
-
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]
