I'll try to answer in some detail as this is a real-world problem that I have always been dealing with, in whatever language, and also it is very easy to misunderstand.
On Oct 1, 2012, at 8:24 AM, Ian East <ian.east@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
As I understand them, PVI is the same as PRI PAR, except that the waiting interrupts do not round-robin, but when they can run, the highest-priority one always goes first. As I understand it, once the ISR is entered, it runs to completion, even if a higher-priority interrupt becomes pending, unless an STI is specifically programmed in the ISR.
This can actually be implemented by a PRI ALT within a single high-priority process that implements all the ISRs.
I almost always prefer the round-robin (even going to the extent of re-prioritizing the interrupts after each ISR fires) because of the danger of starvation. ISRs should be quick, setting bits and counters, and any long-winded response should be in interruptible processes which can be activated in occam by the ISR code. If quick ISRs in a round robin do not produce good enough response, it's usually a sign that your chip is underpowered for the events it is handling. An exception could be if individual serial bytes drive an interrupt.
But you accept this, according to your PS at the end.
That is a head-in-the-sand attitude, since all real implementations of ALT are naturally prioritized. There is a danger of starvation, yes, but you have to specifically program against that. Just running ALT, which legally can be implemented by what amounts to a PRI ALT and is therefore unfair in an uncontrolled way, does not solve any starvation problems.
A loop around a PRI ALT that embraces all the ISRs in one high-priority process would do what you want:
-- All the ISRs are in one high-priority process
INT counter :
counter := 0
counter.event ? signal
counter := counter + 1
event2 ? whatever
-- use counter
event3 ? whatever
-- use counter
Each of the interrupt branches has some soft channel that it uses to trigger the low-priority code (i.e. main loop), and can transmit the counter as needed. Or the PRI ALT can be enclosed in a SEQ and a single triggering channel used, which amounts to an OR of all the interrupts. ALTs (PRI or otherwise) are very useful for broadcasting updates like this, a task NOT well adapted to the "each stimulus has its own thread" approach.
If starvation is a danger, three PRI ALTs can be branched to, based on what fired last, each giving a different priority sequence.
Therefore there is no pre-emption, so it seems to be perfectly modeled by a PRI ALT.