> Almost, but not quite. In your scenario the low-priority task would > get to run since the high-priority task is blocked and would thus > eventually release the resource. No deadlock, no problem. > > The classic priority inversion that I have heard about is the following > scenario: > > Three processes of low, medium and high priority respectively. > The low-priority task locks some resource. Before this resource is > released both the medium-priority and the high-proiority task starts to > run. Since these have higher priority the low-priority task doesn't get > any CPU. The medium-priority task is CPU-intensive and uses all > CPU-time it gets (but it won't get any while the HP-task is running.) > Eventually the high-priority task tries to lock the resource that the > low-priority task is holding. The high-priority task is then blocked > and the medium-priority task gets to run. > > Now the high-priority task is blocked waiting for the resource that the > low-priority task is holding. The LP-task does not get to run since the > MP-task has higher priority and thus can't release the resource. > > This means that the priority between the HP task and the MP task has in > effect been inverted, since the medium priority task blocks the > high-priority task from running even if there is no resource that both > of them are trying to lock. > > The problem is that when the high-priority task got blocked trying to > acquire the resource that the low-priority task held it effectively > inherited the priority of the low-priority task and can therefore be > preempted by the medium-priority task. > > > To get a priority inversion like this one needs at least three tasks > with different priorities.
Ah, yes. I stand corrected :) Thanks, -jj -- Users of C++ should consider hanging themselves rather than shooting their legs off--it's best not to use C++ simply as a better C. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
