Re: Priority inversion and CSP channels?

["P.H.Welch" <P.H.Welch@xxxxxxxxx>]

Hi Gerald,

I guess what they want is that if a process (priority a) gets blocked trying
to communicate with a process (priority b) and (a > b), then the process
that's not ready to communicate should have its priority raised to a.

When ALTing, things get messy.  If the process (priority a) gets blocked on
an ALT, then I suppose all processes at the other end of (write) channels
that have been enabled by the ALT should have their priority raised to a
(if their own priority is less than a).

Problem for both of the above: occam/JCSP/CTJ processes deal with channels,
not other processes.  If the channel is empty (i.e. the process trying to
communicate gets blocked), there is no way to find its partner process -
so how do we raise its priority when required?

It's different with monitors.  If a thread is blocked trying to get a lock
on a monitor, you probably can find out who has the lock (and raise its
priority if necessary).

BUT BUT BUT BUT BUT ...

Priority inversion has always seemed to me a silly problem - one that comes
from bad design in the first place.  Have you got a copy of my paper from
OUG-7: "Managing Hard Real-Time Systems on Transputers" or some title like
that? Also, see chapter 7 of my occam course slides.

My hard real-time rule is: don't communicate with a lower priority process
*unless* you don't have any real-time guarantees to deliver.  Removing the
double negatives, this means feel free to communicate with a lower priority
process (and maybe get blocked) if you currently have no real-time service
committments.

General design pattern: give the high-priority real-time servicing process
an equal-priority buddy process.  When you need to communicate with a lower
priority process, get your buddy to do it.  Your buddy is listening out for
you - so you won't be blocked communicating with your buddy.  Your buddy
then gets blocked (maybe) communicating with the lower-priority process but
no matter - you are still alive and servicing.  You need to remember not
to communicate with your buddy until he communicates back to you to say
that he's dealt with the lower-priority process.  If you really need to
do that, you'll need some more buddies.

What I don't need with the above pattern is any priority raising.  My high
priority buddy can get stuck commincating with a low priority process.
Fine - my buddy hasn't got anything else to do!  That low-priority process
is doing background computation that is not time-critical (else it wouldn't
be low-priority).  The last thing I want is for its priority to be raised
to mine so that it competes with me - I've got real-time duties to service!
My buddy needs to be equal-priority with me so that he will succeed as soon
as the low-priority process is ready to communicate with him *and* so that
he gets my attention when that's been done.

So, I just don't believe in this priority inversion problem ;-)

PRIORITY CEILING PROTOCOL ...

This looks like a clever trick that does two things:

  (1) allows you to drop sync locks on access to a monitor - but *only*
      on a uni-processor!!
  
  (2) avoids the deadlock of partially acquired resource because it
      happens to implement the Resource Alloaction Priority trick.
      But that can be done without reference to actual process priority!

Point (1) is intriguing ...

Lunchtime ...

Cheers,

Peter.