Nick Piggin wrote:
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.
In those cases, A cannot retake the mutex anyway. I.e., you just said
that you released the first mutex because you want to acquire a
different one. So those cases don't fit this example very well.
Another reason might be because we will be running for a very long
time without requiring the lock.
And again in this case, A should not be immediately reacquiring the lock
if it doesn't actually need it.
Or we might like to release it because
we expect a higher priority process to take it.
And in this case, the expected behavior is the same as I've been pursuing.
--
-- 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]
