Messages in this thread | | | From | "David Schwartz" <> | Subject | RE: pthread_mutex_unlock (was Re: sched_yield() makes OpenLDAP slow) | Date | Thu, 26 Jan 2006 11:57:27 -0800 |
| |
> The point of this discussion is that the POSIX spec says one thing and > you guys say another; one way or another that should be resolved. The > 2.6 kernel behavior is a noticable departure from previous releases. The > 2.4/LinuxThreads guys believed their implementation was correct. If you > believe the 2.6 implementation is correct, then you should get the spec > amended or state up front that the "P" in "NPTL" doesn't really mean > anything.
There is disagreement over what the POSIX specification says. You have already seen three arguments against your interpretation, any one of which is, IMO, sufficient to demolish it.
First, there's the as-if issue. You cannot write a program that can print "non-compliant" with the behavior you claim is non-compliant that is guaranteed not to do so by the standard because there is no way to know that another thread is blocked on the mutex (except for PI mutexes).
Second, there's the plain langauge of the standard. It says "If X is so at time T, then Y". This does not require Y to happen at time T. It is X happening at time T that requires Y, but the time for Y is not specified.
If a law says, for example, "if there are two or more bids with the same price lower than all other bids at the close of bidding, the first such bid to be received shall be accepted". The phrase "at the close of bidding" refers to the time the rule is deteremined to apply to the situation, not the time at which the decision as to which bid to accept is made.
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.
DS
- 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/
| |