Talk:Priority inheritance

This doesn't make sense: "Using this programming method, a process scheduling algorithm will increase the priority of a process to the maximum priority of any process waiting for any resource the process has a resource lock on." - ao

It means this: Process A is high priority, and waiting for currently-in-use resource X; process B is low priority, but currently using resource X. Under a normal scheduling system, process B will be scheduled with low priority, so it may hold resource X for a long period of time, thereby blocking high-priority process A. Priority inheritance solves this problem by raising the priority of A to that of B until A releases resource X. The observation is that when a high-priority process depends on a low-priority process running, running the otherwise low-priority process temporarily becomes a matter of high priority. Of course, this has some problems in the face of uncooperative processes: a low-priority process could purposely hold a resource it knows a high-priority process needs for much longer than necessary, in order to raise its priority artificially. [Maybe something like this should be added to the article?] --Delirium 21:39, 14 September 2005 (UTC)

Non-Problems

Basic Priority Inheritance Protocol has TWO Problems:

1. Does not prevent deadlock.

2. Chain of blocking may be formed i.e., blocking duration can be substantial, though bounded.

Comment: Those are both problems in the design of real-time systems, but PIP is not designed to solve them.

1. A Deadlock occurs when we can find a chain $\{(T_{i},M_{i}),0\leq i<n\}$ such that thread $T_{i}$ holds Mutex $M_{i}$ for $0\leq i<n-1$ and $T_{n-1}$ tries to aquire $M_{0}$. In this situation, the system is deadlocked, no matter what the priorities are.
2. Blocking Duration: When we have some $n$ threads $\{T_{i},0\leq i<n\}$ which want to exclusively access the same ressource $R$, each Thread has to wait for zero or more threads to finish. Actually, the (normal) priority of a tread $T$ determines how many other threads $T$ might have to wait for.PIP actually ensures that each thread will get to use $R$ at some time by avoiding priority inversion, which could hold up high-priority tasks for an arbitrary amount of time. Hence, we actually get an estimate about how long a particular task $T$ might have to wait for a ressource $R$. Whether a particular waiting time is accepptable for a particular system is quite another problem.

129.13.72.153 12:02, 1 August 2006 (UTC) mailto:liekweg@gmx.de