Re: Priority revisited: a new primitive

[tjoccam@xxxxxxxxxxxxx (Lawrence Dickson)]

All,
   Barry has a strong point with respect to the nuclear reactor.
   Going back to experience, the dispute seems somewhat to be a
distinction without a difference, because PRI PAR was used like
"top half" interrupt code: in and out "instantly" so as to set up
a proper response to interrupt conditions. You had to do your real
prioritizing by software outside of that. I believe this is the only
practical, real-world solution: multiple priorities are just kidding
yourself.
   In the one case where I had to have very rapid response (I was
generating an RS232 serial waveform from scratch), I had to allow only
one high priority process. This, too, is realistic, I think. You will
have to code the response to the nuclear reactor in this process, and
code it efficiently too...

> Subject: Re: Priority revisited: a new primitive
> To: ireast@xxxxxxxxxxxxx (p0072370)
> Date: Tue, 10 Oct 2000 16:31:33 +0100 (BST)
> Cc: b.m.cook@xxxxxxxxxxxxxx (B.M. Cook), occam-com@xxxxxxxxx (Occam list),
>         ianeast@xxxxxxxxxxxxxxx (ianeast),
>         adrian.lawrence@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx (A E Lawrence)
> Message-Id: <E13j1NO-00004d-00@xxxxxxxxxxxxxxxxxxx>
> From: "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 agree very strongly, but the use of PRI PAR (Transputer style) with
cycle counting should be OK for most practical problems. The response
time needed is in milliseconds or seconds, the cycles are
sub-microsecond; if we can't design a proper program to do this, we are
not very good programmers. But is this implementation outside the range
of CSP?

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

NO I THINK NOT... You have to be able to justify yourself in real time
to do embedded apps.

Larry Dickson