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 [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]
