Re: Priority revisited: a new primitive

[p0072370 <ireast@xxxxxxxxxxxxx>]

Barry said:
>In (extreme?) situations such as the reactor problem I really would prefer
>it to shut-down rather than be a "Sorry, it was the best we could do"
>disaster.
>
>Dev tools can probably satisfy us both; e.g. Xilinx's FPGA tools allow you to
>specify a target performance and either creates a design that passes, or one
>that fails with a report of the best it could manage. (However, I'd like the
>person who agreed that a failed system could run the reactor to be
>accountable for the decision.)
>
>I'm not sure that time isn't important. Look at the London Ambulance's "best
>we could do" - a real time was needed. There are many time critical
>situations, air traffic control, railway signalling, health service, even
>how long it takes a vending machine to produce a cup of coffee makes a
>difference. As I look around at real applications, it seems that bounded
>delivery time is very important.
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 remain 
extremely sceptical about introducing real-time dependency into a program 
because that MUST conflict with the separation of program and platform. 
Priority surely does not introduce such conflict.

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).

Cheers
Ian


Dr. Ian Robert East
01865 483635
Room T656, Tonge Building
School of Computing and Mathematical Sciences
Oxford Brookes University

2000/2001 Term 1 Consultation hours:
Tuesday   11.00..12.00; 12.00..13.00
Friday    10.00..11.00; 12.00..13.00