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

Howard Chu wrote: 
Nick Piggin wrote:

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.


But why does A take the mutex in the first place? Presumably because it is about to execute a critical section. And also presumably, A will not release the mutex until it no longer has anything critical to do; certainly it could hold it longer if it needed to.

If A still needed the mutex, why release it and reacquire it, why not just hold onto it? The fact that it is being released is significant.


Regardless of why, that is just the simplest scenario I could think
of that would give us a test case. However...

Why not hold onto it? We sometimes do this in the kernel if we need
to take a lock that is incompatible with the lock already being held,
or if we discover we need to take a mutex which nests outside our
currently held lock in other paths. Ie to prevent deadlock.

Another reason might be because we will be running for a very long
time without requiring the lock. Or we might like to release it because
we expect a higher priority process to take it.

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.


In the last RT work I did 12-13 years ago, there was only one high priority producer task and it was never allowed to block. The consumers just kept up as best they could (multi-proc machine of course). I've seldom seen a need for many priority levels. Probably not much you can generalzie from this though.


--
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)
    ... need the exclusion provided by the lock for a very long time so it drops it to avoid needless contention, then reaquires it when it finally does need the lock. ... other threads that were blocked on that mutex could do useful work in the interim without impacting A's progress at all. ... the SUS discussion of priority inheritance would never need ... In a priority-driven environment, a direct use of traditional primitives like mutexes and condition variables can lead to unbounded priority inversion, where a higher priority thread can be blocked by a lower priority thread, or set of threads, for an unbounded duration of time. ...
    (Linux-Kernel)
  • [PATCH -mm] Update rt-mutex-design.txt as per Randy Dunlap suggestions
    ... The classic example of unbounded priority inversion is were you have three ... A tries to grab a lock that C ... the PI locks will be called a mutex. ... The mutex structure contains a pointer to the owner of the mutex. ...
    (Linux-Kernel)
  • Re: FUSYN and RT
    ... >> to hold a fusyn lock, then block on an RT lock. ... >> will be problems when the RT mutex tries to restore the priority. ...
    (Linux-Kernel)
  • Re: pthread_mutex_unlock (was Re: sched_yield() makes OpenLDAP slow)
    ... time without requiring the lock. ... A should not be immediately reacquiring the lock if it doesn't actually need it. ... other threads that were blocked on that mutex could do useful work in the interim without impacting A's progress at all. ... the SUS discussion of priority inheritance would never need ...
    (Linux-Kernel)
  • Re: Recursive mutex that can be waited upon (pthread)
    ... While you can use a mutex to avoid that data is changed, for me having a mutex does not mean that data is not changed, it only means that data is not changed by a different thread. ... My own thread may of course change the data, hence functions I call may want to change the data and if they do so, they must be sure that these changes are atomically, hence they must lock the object and they simply can't rely that I locked the object before -> thus I need recursive locks. ... Then I could as well throw out threads of my code and just use a single thread going through an event queue. ... you have a predicate condition on an invariant. ...
    (comp.programming.threads)