Your example has nothing to do with the problem that priority inheritance is
meant to solve. Your adding a second problem to the example that has a
different solution.
In your example, Process 0 takes Lock 0. Then Process 1 takes Lock 1. Then
Process 1 tried to take Lock 0. You have a deadlock, but not one that
priority inheritance is meant to solve. P0 and P1 could both be running at
the same priority and you'd still deadlock.
If Process 0 and Process 1 both want to lock Lock 0 and Lock 1, then they
should always attempt to get the locks in the same order.
So the right way for this is, Process 0 takes Lock 0. Process 1 wants to
lock Lock 1, but in order to do that, it must first lock Lock 0. No
deadlock.
___________________________________________________________
Mark Levitt Not reading coffee in cup A:
Technical Writer Abort, Retry, Panic?
Citrix Systems
http://www.citrix.com
___________________________________________________________
-----Original Message-----
From: Victor Yodaiken [mailto:yodaiken@ladron.cs.nmt.edu]
Sent: Wednesday, February 10, 1999 11:23 AM
To: p.steiner@t-online.de
Cc: linux-kernel@vger.rutgers.edu
Subject: Re: Real Time scheduler?
>
>
> >Consider Process 0 ... 255 share a 1000 file descriptors in some
>
> Hmm, I don't understand that example. I'm not an expert in this so
> correct me if I'm wrong:
>
> You have a low priority process P0 waiting on FD{0}.
>
> Then high priority P1 also waits on FD{0}. I guess there's no priority
> queue, so first P0 gets unlocked and then P1? In this case P0 must
Suppose Pi has higher priority than P_{i-1}.
Even if there is a priority queue, once P0 has the lock, P1 must wait
until P0 unlocks. So, you promote the priority of P0 to equal that of P1
and then P2 runs and reaches the lock. Then P0 is promoted again etc.
Or worse, as in my example, P0 has lock L0 and P1 locks L1 and then
hangs on L0, and P3 locks L3 and then L2 .... so that priority promotions
are cascaded
> When P0 leaves for whatever reason it simply gets it's original
> priority back. What do you want to recalculate here in P1 or P2?
This is one of the choices of wrong answers. Suppose P0 has lock L0
and lock L1 and gets promoted on both of them. If unlocking either
returns P0 to its original priority then you still have inversion, if
you need to look at all held locks/resources then you have a rather
significant overhead.
> You don't have that problem if the queue gets reorderd by priority,
> since then P0 wouldn't get a higher priority at all. The only situation
> where P0 needs to get higher priority is when it actually got the lock
> and tries to continue execution. In this case it needs to inherit the
> priority of the first process in the queue until it reaches the unlock.
See above.
> >And then consider how a kernel that depends on the operation of many
daemon
> >processes will continue to operate when users can introduce arbitrarily
many
> >"RT" processes that can block daemons indefinitely.
>
> Users can only lower priority.
Not in the soft RT scheme.
> The easiest solution seems to be to give all processes at least a small
> minimum timeslice and to not inherit anything. Then things basically
> work like they already work. Just that nice processes will be much
> nicer than currently.
That is a much better solution. It's compatible with the general
unix design and can be implemented very efficiently.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/