[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Priority Inversion in Monitors.

Now that we're in scope for it, I'll resend a letter I sent
to this group middle August last year, which envoked no
response at the time (slightly edited):


In "Doing Hard Time" - Developing Real-Time Systems with UML,
Objects, Frameworks, and Patterns by Bruke Powel Douglass, p.563
the author states this:

When he comes to the Priority Ceiling Protocol PCP he says that 
it "totally eliminates deadlock". 

Previously he has limited context to "priority-based" and 
"preemptive scheme", (p561) and problems with not-paired 
ordering of nested acquirement of locks (p562). 

Q1. I seem to remember that nested ACQUIRE should not be legal
    in occam 3. This should also "totally eliminate deadlock"?
Q2. In _this_ sense CSP is also totally elmininated from deadlocks,
    since he seems not to talk about pathological communication
    paths between processes, but wrongly used locking primitives?
Q3. Is it at all correct to limit deadlock discussion this much,
    without making clear that process deadlocks are not discussed?
Q4. Have I misunderstood everything in the sense that he really is
    _also_ talking about user process deadlocks?
Q5. With the occam3 solution, I conclude that preemption does not
    have anything to do with this. Still the authror's discussion
    mentions preemptions so much that I don't know. Is preemption
    vs. f.ex. non-preemptive schemes essemtial for this discussion?

Added 3Feb2000:

In Real-Time Magazine 4-99 (Missed it! - How Priority Inversion 
messes up real-time performance and how the Priority Ceiling 
Protocol puts it right) -
the author states that:

"With PCP a given task is blocked at most once, even when locking
several semaphores. A side-effect of this property is that a system
using PCP to lock semaphores is guaranteed to be deadlock free."

This perhaps answers my question? PCP isn't better than CSP - 
that's like comparing the y and the x axises, isn't it, ie. 
deadlock is still the gravitational force of concurrency, that
holds us down?

|        Oyvind Teig |          oyvind.teig@xxxxxxxxxxxx |    |    |
|  Navia Maritime AS |          oyvind.teig@xxxxxxxxxxxx |    |    |
| division Autronica |                                   |Tel:|Fax:|
|               7005 |               http://www.navia.no | +47| +47|
|          Trondheim |           http://www.autronica.no |7358|7391|
|             Norway | http://www.autronica-maritime.com |1268|9320|