======= LSN005.IntHand =======


A Short Language Study Note on Interrupt handlers as Protected Procedures

Offer Pazy

March 26, 1991

Introduction:

In past discussions, various people have expressed some concern that the
fact that we propose to use protected records as interrupt handlers is 
artificial, arbitrary, and can cause unnecessary overhead and limitations 
in both constructs to accommodate each other.  Some went even further to 
suggest that we should allow any parameterless, library level procedure 
to act as an interrupt handler.

The purpose of this short LSN is to elaborate on why we think this is a 
very natural unification, one that will hopefully not result in any of the
consequences mentioned above.

Background:

Originally, we have developed the idea of interrupt handlers and data
synchronization primitives quite separately.  We did not immediately see
the similarities in their functional requirements.  Only later, we have 
realized that there is a lot of commonality between the two from a 
functional and operational perspectives.  (i.e. we have never looked at
it as just a convenient way to lump the two together, and save MI's...)

Why protected procedures and interrupt handlers are similar ?

There are several properties which we believe are inherently shared between
traditional interrupt handlers and non-queued mutual-exclusion primitives.
(In this note I assume that it is a given that we need such a primitive.) 

 o The code in both sections should usually be very short and bounded in time.

 o No blocking operations are possible from within the sequence of statements.
   (In the case of interrupt handlers, the state of the interrupted RTS is
   usually unknown at the time of the interrupt, therefore, it is impossible 
   to support a complete suspension and context-switch without introducing
   special mechanisms.)  This requirement implies certain restrictions on the 
   allowable constructs in those sections.

 o The context in which the sequence of statement execute should be fairly 
   limited and "simple".  In the case of interrupt handlers this is
   because we don't want to spend the time necessary to save the full old
   context and establish a new one.  This is true for traditional interrupt
   handlers (i.e. in other real-time kernels), but particularly critical
   in the case of Ada where the task's context is not a trivial one.  With 
   protected procedures, the need for a limited context comes from our desire
   to allow entry bodies to execute arbitrarily by any task which finds the
   corresponding barrier to be true.  Even though "context" and "context-
   switches" are often referred to as implementation issues, in real-time
   applications, they are not, and they represent an application-visible
   action.  If a task, when evaluating a barrier, would have had to fully
   switch to the corresponding task, we would lose much of the intended 
   functionality and efficiency of the primitive (this is true in general
   for conditional critical sections in real-time).

 o Finally, the occurrence of an interrupt and the execution of a critical 
   section both introduce the possibility of priority inversions.  To
   minimize that effect, they all should be tied to the same priority model 
   in the system, be governed by the same scheduling policy and the same 
   scheduler.

Conclusion:

It is very difficult to completely separate issues of functionality and
implementation in either real-time or performance-sensitive applications.
The above points represent what we believe are functional requirements of
a language which supports real-time applications.  The derivation of these 
requirements leads to adopt a similar language construct which in turn will 
share a common implementation model.  (Not the other way around !).  We 
believe that no overhead or undue limitations are introduced by this natural 
unification.