[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Programming prioritisation



Hi Larry

The semantics of PRI PAR, PRI ALT and my when (intended to reflect prioritised vectored interrupts (PVI)) are quite different.

PRI ALT is merely a 'choice' operator, i.e. a selection, with no pre-emption.  If something more important demands a response once the choice is made then tough.  It also presents problems when combined in parallel with others of its ilk, causing Bill Roscoe (Understanding Concurrent Systems (UCS), p.487) to abandon "prioritised choice".

Whatever approach we take, a 'global' prioritisation of events must be declared, with scope encompassing the entire system affected.

PRI PAR is closer to PVI but runs into considerable semantic difficulty :
–  since, by definition, prioritised processes cannot run concurrently, time-slicing via a scheduler
is merely a convenience, obscuring the reality, especially when they communicate via rendezvous
–  the construct reduces to become meaningless, should enough processors become available to run
every process independently (which may be acceptable in practice, but not in theory, since we'd like
the meaning of any program to remain the same, without regard to the platform on which it runs);
then again it may not be acceptable in practice.

Note that, as with PRI ALT, the problem of composition can be overcome with a declaration of prioritisation that has adequate scope.

What I seek, and what I think is required for simple, transparent programming of many behaviours must reflect multiple ways in which to interact with a single process, not dissimilar to multiple 'methods' with a single object.  The simplest example I can come up with, which is trivial to implement on the humblest micro which supports PVI, is where a single event requires no response but must be counted, and where that count affects somehow the response to other events.  This is pretty tricky to accomplish with PRI PAR, and has no use for PRI ALT.

The test of a language is whether there are simple, transparent solutions to simple problems.  I still want a 'when' construct, in lieu of PVI.

I'm of the opinion that shared variables have their rôle to play, and that we should find a way to understand them better in order to use them safely.  (UCS does address them, but I have yet to find the time to pursue this further.

Ian
PS In the description of 'when' below, P, Q, … would each run to termination, following their guard event.  I should add that the same difficulty in both interpreting and implementing 'fairness' exists as with ALT (selection/choice).

On 1 Oct 2012, at 15:02, Larry Dickson wrote:

However, I never bought the PRI constructs, especially given two of them.  What I wanted was :

when
  event a then
P
event b then
Q

in prioritised order of pre-emption, not PRI ALT or PRI PAR (and certainly not both).  But how do P and Q safely communicate?
(I need to formalise this construct, I know.)

I never found that a problem. The only thing I have no use for is ALT (everything in the real world is PRI ALT; you have to work rather hard to get a fair ALT), but PRI ALT (in a loop) is the exact formalization of the construct you gave.

I am a strong proponent of the Transputer-occam PRI PAR, which addresses a completely different problem from PRI ALT. It is a language feature that embraces both standard "main" code and interrupt code. Most chips enter ISRs with interrupts disabled and remain that way until you IRET, unless you specifically program an STI, and this is just what PRI PAR does. That causes the interrupts to "round-robin" which had better be OK (assuming you are writing "slim" ISRs) because otherwise your event response burden is too much to handle. Bulky "soft" interrupt response code can be in "main" interruptible space, prioritized, almost always, by PRI ALT and booleans.

The beauty of PRI PAR is that interrupt code does not have to be some weird, alien beast that is totally different from "regular" code.



Ian East
Open Channel Publishing Ltd.
(Reg. in England, Company Number 6818450)