[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Priority revisited: a new primitive
>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"
>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
Dr. Ian Robert East
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