RE: [PATCH] Abstracted Priority Inheritance for RT

["Perez-Gonzalez, Inaky" <inaky.perez-gonzalez@intel.com>]

>From: linux@horizon.com [mailto:linux@horizon.com]
>>> I'm not sure I see how this could become recursive, could you
explain
>>> more?
>?
>> Maybe he is referring to the case?
>>
>> A owns M
>> B owns N and is waiting for M
>> A is trying to wait for N
>
>No, that's just a straight deadlock and a bug whether you have PI oir
not.
>The recursive concern is the following case:

Agreed, it is deadlock (as I said), but it is where your
code can go to infinite recursion if you don't have the safeguards
in. 

Calling it a bug depends on what are the "standards" of your code.
Some people consider it good enough and just expect that if you
get an -EDEADLK it means you have already locked the structure and
can go into the atomic section. 

Not that I agree, but the point is YMMV depending on who is using it
and for how.

>Process priorities: A < B < C < ...
>
>Process A holds lock 1
>Process B holds lock 2 and is trying for lock 1
>Process C holds lock 3 and is trying for lock 2
>Process D holds lock 4 and is trying for lock 3
>
>Now see what happens when high-priority process E tries to
>take lock 4.  We need to push its priority all the way down
>the chain to process A.

Well, this is normal priority propagation to a not-trivial
ownership-wait chain. Or PI transitivity (I think I've heard
it called like this).

>If a process is only allowed to try for one lock at a time, that could,
>in theory, be done iteratively, but it might take some care.

It can be done iteratively in all cases (at least the fusyn code
does). 

>Actually, the tricky part of priority inheritance implementation is
>usually dropping the priority properly when locks are released.

No if you stack the priorities (again, look at the fusyn code,
or better at the OLS paper, don't have time to give the full
rundown again). Then it becomes a very simple matter of popping 
the first item in your priority stack. 

-- Inaky
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/