Re: Priority revisited: a new primitive

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

Ian said:
> I actually take the other view. IMHO it's PRIORITY that's fundamental. 
> Real time I regard as an implementation issue. Prioritization can yield 
> the best that can be done, leaving the dev tools to let you know how long 
> things take on any specific platform etc.
> 
> Partly, this is political, and reflects my loathing of deadlines, which 
> to me seem a marvellous way of passing the blame downwards and evading 
> responsibility at higher levels. But maybe that's just my inate inability 
> to accept authority...

I'm willing to be convinced  - I have no earth-saving counter offer, just
doubts about what we are currently offered.

I may have the same problem with "authority" as I'm always asking if there
isn't another or a better way to do things.

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'd rather let a CAD system produce an answer for me than to miss lunch
trying different solutions until I find one that works.

-- Is this looking a bit too much like a hobby horse? Sorry --

	    Barry.