Re: Priority revisited: a new primitive

["B.M. Cook" <b.m.cook@xxxxxxxxxxxxxx>]

> I agree completely that real-time, and that guaranteeing a response 
> within a satisfactory interval, is frequently critical. The issue surely 
> is how one can make such guarantees. Ultimately, execution time depends 
> upon the platform. Behaviour should, as far as can possibly be achieved, 
> depend upon the program, and specifically NOT the platform. 

I place time requirements on an equal with data requirements - behaviour
includes both data and time. (In this media-over-the-Internet age we are
finding situationd where time is more important than data, e.g. fuzzy
movies are better than jumpy movies.)

>                                                             I remain 
> extremely sceptical about introducing real-time dependency into a program 
> because that MUST conflict with the separation of program and platform. 

When it comes to system design, you need to work with the whole system and
separation isn't possible.

BUT

The reasons for separation of program and platform that we are used to are
still valid. I am most emphatically not suggesting returning to writing
platform specific code, quite the opposite - I'd like even higher levels of
abstraction so that tools can help us. Adding time constraints just gives
the compiler more information to use when optimising (e.g. to bias the
size/speed trade-off - I want the compiler to decide to inline functions,
move bits of code to hardware, etc. by itself)

> Priority surely does not introduce such conflict.

I am re-assured by the discussion in this group that it may not be as bad as
I'd thought. However, I haven't been persuaded that priority isn't too low a
level statement. It appears to be a thing you can derive from a primary
requirement.  Looking at, for example, Stallings' "Operating Systems" (2nd
edition) ~page 400 on real-time scheduling, the examples assign priority (often
dynamically changing) as a short-term mechanism to achieve a higher-level
time constraint. [Tucked into these pages I find copies of emails from March
1999 discussing these and related issues - time to dig in the archives?]

I AM concerned that all the requirements are stated up-front (I guess it is
part of a realisation that it is difficult to aim at a target until you know
what the target is).

I completely agree that time requirements will force a
designer/verifier/design-tool to take a broader view. The platform is
hardware, operating system, other programs, etc.  Maybe I'm lookin quite a
long way into the future but I guess that's what I should be doing (see
Marcel's classification).

> It seems to me that one could make guarantees only by asking questions, 
> not of the program, but of a particular build (combination of program and 
> platform).

YES.  I don't see that as a reason not to state my requirements.

              Barry.

-- 
/----------------------------------------------------------------------------\
| Barry M Cook, BSc, PhD, CEng, MBCS                                         |
| Senior Lecturer,                           Department of Computer Science, |
| Chartered Information Systems Engineer.    Keele University,               |
|                                            Keele,                          |
| Phone: +44 1782 583411                     Staffordshire,                  |
| FAX:   +44 1782 713082                     ST5 5BG,                        |
| email: barry@xxxxxxxxxxxxxx                UK.                             |
\----------------------------------------------------------------------------/