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

Howard Chu wrote: 
David Schwartz wrote:


The time at which the decision takes effect is immaterial; the point is that the decision can only be made from the set of options available at time T.

Per your analogy, if a new bid comes in at time T+1, it can't have any effect on which of the bids shall be accepted.

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.


OK, you believe that the mutex *must* be granted to a blocking thread
at the time of the unlock. I don't think this is unreasonable from the
wording (because it does not seem to be completely unambiguous english),
however think about this -

A realtime system with tasks A and B, A has an RT scheduling priority of
1, and B is 2. A and B are both runnable, so A is running. A takes a mutex
then sleeps, B runs and ends up blocked on the mutex. A wakes up and at
some point it drops the mutex and then tries to take it again.

What happens?

I haven't programmed realtime systems of any complexity, but I'd think it
would be undesirable if A were to block and allow B to run at this point.

Now this has nothing to do with PI or SCHED_OTHER, so behaviour is exactly
determined by our respective interpretations of what it means for "the
scheduling policy to decide which task gets the mutex".

What have I proven? Nothing ;) but perhaps my question could be answered
by someone who knows a lot more about RT systems than I.

Nick

--
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/

Relevant Pages

  • Re: pthread_mutex_unlock (was Re: sched_yield() makes OpenLDAP slow)
    ... unlocker was a lower priority thread and there are higher priority threads blocked on the mutex, you really want the higher priority thread to run. ... the time at which the decision as to which bid to accept is made. ... If the policy is to make a conditional or delayed decision, that is still perfectly valid policy. ... 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/ ...
    (Linux-Kernel)
  • RE: pthread_mutex_unlock (was Re: sched_yield() makes OpenLDAP slow)
    ... > The point of this discussion is that the POSIX spec says one thing and ... the time at which the decision as to which bid to accept is made. ... policy" shall decide, not that the scheduler shall decide. ... "Whichever thread requests it first" is a valid scheduler policy. ...
    (Linux-Kernel)
  • Re: pthread_mutex_unlock (was Re: sched_yield() makes OpenLDAP slow)
    ... because the thread that just released the mutex is obviously not one of the threads blocked on the mutex. ... When a mutex is unlocked, one of the *waiting* threads at the time of the unlock must acquire it, and the scheduling policy can determine that. ... If the kernel doesn't actually determine the new owner of the mutex until the currently running thread swaps out, it would be possible for the currently running thread to re-aquire the mutex. ...
    (Linux-Kernel)
  • Re: pthread_mutex_unlock (was Re: sched_yield() makes OpenLDAP slow)
    ... The policy can decide *which of the waiting threads* gets the mutex, but the releasing thread is totally out of the picture. ... The mutex functions are a core part of the thread specification; they have a fundamental behavior, and the definition says if there are blocked threads waiting on a mutex when it gets unlocked, one of the waiting threads gets the mutex. ...
    (Linux-Kernel)
  • Re: pthread_mutex_unlock (was Re: sched_yield() makes OpenLDAP slow)
    ... policy can decide *which of the waiting threads* gets the mutex, but the releasing thread is totally out of the picture. ... Yielding at the unlock or blocking at the lock will increase the dreadlock over the larger mutex. ... scheduling policy, POSIX makes no guarantees of fairness, such as "the ...
    (Linux-Kernel)