Talk:Priority inheritance

From Wikipedia, the free encyclopedia

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)

[edit] 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 such that thread T_i holds Mutex M_i for and T_{n − 1} tries to aquire M₀. In this situation, the system is deadlocked, no matter what the priorities are.
2. Blocking Duration: When we have some n threads 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