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