[gclist] Mars Rover info from comp.risks

[Jerry Leichter]

Two things:

1.  RMA started off by dealing entirely with periodic processes, but has been
extended to deal with aperiodic - "interrupt-driven" - processes.  Further,
while it can be used as an up-front analysis technique of a fixed set of
processes (the way it was initially presented), it's much easier to use if
integrated with the scheduler:  You present your requirements to the
scheduler, it does the RMA calculations for the current processes plus your
requests, and if it can find a feasible schedule it lets you in.  In some
sense, there are certainly priorities "under the covers", since the schedule
allows certain processes to pre-empt other ones, but you don't see them
(unless you look at the internals) and you certainly don't set them.  So,
while it's true that "RMA" stands for "Rate Monotonic Analysis", and that at
some level priorities are involved, these are both issues at the wrong level
of abstraction for understanding how a system that uses rate monotonic
scheduling is programmed.

Anyone interested in the details of this stuff - there's a *lot* of work out
there, of (of course) varying quality - might want to start with Raj
Rajkumar's page (http://www.cs.cmu.edu/afs/cs.cmu.edu/user/raj/www/raj.html).
I suspect Mr. Riccardi can give us an appropriate reference for work being
done an INRIA, too.

2.  Priority inheritance for condition variables is a big issue exactly
because "condition variables" as defined in current thread standards are very
unstructured control objects.  You just can't tell who might signal a
condition variable.

Consider, however, that what is called a "condition variable" today is not the
same as what was called a "condition variable" when Hoare introduced them for
use in monitors.  In a Hoare monitor, a condition variable is scoped to be
accessible only inside of one monitor, and further the monitor's semantics is
such that only one thread can be "in the monitor" at a time.  Hence, you know
whose priority to raise:  When any process enters the monitor, its priority is
raised to match the highest priority of any process waiting to enter the same
monitor.  The relevant "resource" is the monitor itself, and the compiler/run
time system always knows 

With the modern notion of "condition variable", there is no way to know what
resource the CV is associated with - that's purely a matter of coding
convention.

BTW, this is *not* true of Java - at least not in the basic language.  There
are no independent condition variables.  Rather, each object is itself a
monitor, containing a lock and an anoymous condition variable which you can
notify() or wait() on.  If you only use these along with synchronized methods
in runnable objects, you get exactly Hoare-style monitors (albeit with the
restriction that you can only have one condition per monitor).  Even if you
wait() on or notify() other objects, where those objects themselves are the
relevent resources, automatic priority inheritance should be possible with
little effort.

On the other hand, nothing prevents you from using an object as a CV in and of
itself, controlling access to some other "resource" that exists only in your
design and nowhere in a form a compiler or run-time support package could
understand.  In that case, you're on your own.

(Conversely, you *can* enforce a style of usage for Posix condition variables
that would allow for priority inheritance.  Of course, you'd need a scheduler
that understood your conventions and made use of them - a non-trivial thing.
But, hey, we're talking the C/C++ philosophy here:  Let the programmer do
anything he wants, then (try to) pick up the pieces later.)

							-- Jerry