Talk:Priority inheritance

This article is rated Stub-class on Wikipedia's content assessment scale.
It is of interest to the following WikiProjects:

Computing

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
???	This article has not yet received a rating on the project's importance scale.
	This article has been automatically rated by a bot or other tool as Stub-class because it uses a stub template. Please ensure the assessment is correct before removing the `\|auto=` parameter.

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)[reply]

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.

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.
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[reply]