CVS difference for ais/ai-00121.txt

Differences between 1.1 and version 1.2
Log of other versions for file ais/ai-00121.txt

--- ais/ai-00121.txt	1998/09/30 00:17:20	1.1
+++ ais/ai-00121.txt	1999/07/29 00:51:01	1.2
@@ -1,5 +1,6 @@
-!standard C.3.1    (07)                               97-08-19  AI95-00121/04
+!standard C.3.1    (07)                               99-07-28  AI95-00121/05
 !class binding interpretation 96-04-04
+!status Corrigendum 2000 99-07-28
 !status WG9 approved 96-12-07
 !status ARG approved 11-0-1  96-10-07
 !status work item (letter ballot was 10-1-1) 96-10-03
@@ -10,7 +11,7 @@
 !difficulty Hard
 !subject Pragma Attach_Handler on Nested Objects
 
-!summary 96-09-15
+!summary
 
 A program execution is erroneous if the handlers for a given interrupt
 attached via pragma Attach_Handler are not attached and detached in a
@@ -20,7 +21,7 @@
 the same interrupt is not the same as the one that was attached at the
 time the protected object was created, then execution is erroneous.
 
-!question 96-07-23
+!question
 
 C.3.1(7-8) says:
 
@@ -61,14 +62,16 @@
 What is meant by "previous handler" here?  Does this feature make sense
 in a multi-tasking situation?
 
-!recommendation 96-07-23
+!recommendation
 
 (See summary.)
 
-!wording 96-07-23
+!wording
 
-!discussion 96-07-23
+(See corrigendum.)
 
+!discussion
+
 The notion of restoring the "previous handler" only makes sense if
 objects are created and destroyed in a stack-like (LIFO) manner.  In a
 multi-tasking program, it is possible to do otherwise -- for example,
@@ -132,8 +135,47 @@
 was installed at the time the current object was initialized, or the
 handler that was most recently installed before the current one.  For
 all non-erroneous situations, these two are the same handler.
+
+!corrigendum C.03.01(12)
+
+@drepl
+When a protected object is finalized, for any of its procedures that are
+attached to interrupts, the handler is detached. If the handler was attached
+by a procedure in the Interrupts package or if no user handler was previously
+attached to the interrupt, the default treatment is restored. Otherwise,
+that is, if an Attach_Handler pragma was used, the previous handler is
+restored.
+@dby
+When a protected object is finalized, for any of its procedures that are
+attached to interrupts, the handler is detached. If the handler was attached by
+a procedure in the Interrupts package or if no user handler was previously
+attached to the interrupt, the default treatment is restored. Otherwise, that
+is, if an Attach_Handler pragma was used and the most recently attached handler
+for the same interrupt is the same as the one that was attached at the time the
+protected object was created, the previous handler is restored.
+
+!corrigendum C.03.01(14)
+
+@dinsa
+If the Ceiling_Locking policy (see D.3) is in effect and an interrupt is
+delivered to a handler, and the interrupt hardware priority is higher than
+the ceiling priority of the corresponding protected object, the execution of
+the program is erroneous.
+@dinst
+If the handlers for a given interrupt attached via pragma Attach_Handler are
+not attached and detached in a stack-like (LIFO) order, program execution is
+erroneous. In particular, when a protected object is finalized, if any of its
+procedures are attached to interrupts via pragma Attach_Handler, then if the
+most recently attached handler for the same interrupt is not the same as the one
+that was attached at the time the protected object was created, the execution is
+erroneous.
+
+!ACATS test
+
+This ruling makes some executions of Attach_Handler erroneous, so it is not
+testable.
 
-!appendix 97-08-19
+!appendix
 
 !section C.3.1(07)
 !subject Nesting of statically-attached interrupt handlers does not make sense
@@ -158,7 +200,7 @@
 
 One of the design goals of the System Programming Annex was to allow the
 nesting of interrupt handlers.  That is, we envisioned a requirement,
-for large, multi-mode, systems, in which different modules are responsible 
+for large, multi-mode, systems, in which different modules are responsible
 for a given interrupt at different times, and hence different handlers need
 to be attached, detached, and restored(!) dynamically. In general, the idea
 in Ada in to limit the places where limitations are placed on non-library
@@ -177,10 +219,10 @@
 Note a little-known rule in (7,8). The rules for dynamic attachment and
 static attachment are different on purpose.  For both, the protected type
 needs to be at a library level, but for the dynamic attachment (through the
-Interrupts package), the protected object itself must also be at the library 
+Interrupts package), the protected object itself must also be at the library
 level, while for the static attachment, the object can be deeper.
 
-The rationale (C.3.1) discusses these issues and the reasons of why we did 
+The rationale (C.3.1) discusses these issues and the reasons of why we did
 not allow nesting in the dynamic case.
 
 The problem:
@@ -189,7 +231,7 @@
 The problem is that this all idea is not fully thought about. I think we
 had (mostly I had) a temporary fading of the brain in the sense that Ada
 appear to be a multi-tasking environment and in such an environment the
-above model does not make much sense. "Modes" are not necessarily nested 
+above model does not make much sense. "Modes" are not necessarily nested
 within tasks. While a given scope is entered in one task, other tasks may
 still be running "in a scope" that still has attached interrupts.  What
 will happen is that one task will "steel" the interrupt from another
@@ -199,25 +241,25 @@
 connected to the interrupt. A "correct", but also impractical model would
 be that the attachment of interrupts are assumed part of the task context
 and are therefore being switched in and out on each context-switch.  This
-is clearly undesired and not very feasible. Imagine task T1 talking to some 
+is clearly undesired and not very feasible. Imagine task T1 talking to some
 piece of hardware, sending some request and then waiting for the response;
-task T2 then is dispatched and it elaborates a PO to be the handler of the 
+task T2 then is dispatched and it elaborates a PO to be the handler of the
 corresponding interrupt.  T2 now receives a meaningless interrupt while T1
-loses its. Since this is affected by the preemption and scheduling rules, it 
-is 
-largely asynchronous. We did not specify any synchronization (or signalling) 
-rules to require a disciplined usage of this capability, not that I see a 
+loses its. Since this is affected by the preemption and scheduling rules, it
+is
+largely asynchronous. We did not specify any synchronization (or signalling)
+rules to require a disciplined usage of this capability, not that I see a
 simple way to define such rules.
 
 One may claim that this is all a user problem and the designer should make
 arrangements so this will never happen. While correct in principle, we
 don't provide mechanisms to coordinate this. Any safe usage of this feature
 will require resorting to either one task in the partition doing the
-attachment/detachment, or using some other guidelines that essentially 
-reduce 
+attachment/detachment, or using some other guidelines that essentially
+reduce
 the multi-tasking to a single task (or coroutines implemented as multiple
 tasks). Nested attachment of handlers would make perfect sense in a single
-tasking environment. But if this is the limitation, it can already be done 
+tasking environment. But if this is the limitation, it can already be done
 with the dynamic form of attachment.
 
 Implementing this requirement is also not trivial. Never mind, the useless
@@ -247,11 +289,11 @@
 modify the above references and to disallow non-library level objects for
 the static case as well.
 
-Whatever the solution is, we should make sure that we don't lose the other 
+Whatever the solution is, we should make sure that we don't lose the other
 feature of statically-attached handlers, and that is the ability to support
 attachment at pre-elaboration time (i.e. for library-level objects). I
-think that it is still important to be able to ensure that interrupt 
-handlers 
+think that it is still important to be able to ensure that interrupt
+handlers
 are installed as early as possible in the program startup.
 
 Offer Pazy
@@ -296,7 +338,7 @@
 that sounds very dynamic for a "static" feature (Attach_Handler needs
 more dynamic work than Ada.Interrupt and Interrupt_Handler...).
 
--- 
+--
 Laurent Guerby <guerby@gnat.com>, Team Ada.
    "Use the Source, Luke. The Source will be with you, always (GPL)."
 
@@ -327,31 +369,31 @@
 -Tuck
 --------------------
 > C.3.1:
-> 
+>
 > | 12   {finalization (of a protected object)} When a protected object is
 > | finalized, for any of its procedures that are attached to interrupts, the
 > | handler is detached.  If the handler was attached by a procedure in the
 > | Interrupts package or if no user handler was previously attached to the
 > | interrupt, the default treatment is restored.  Otherwise, [that is, if an
 > | Attach_Handler pragma was used,] the previous handler is restored.
-> 
+>
 > |         12.a   Discussion:  Since only library-level protected procedures can
 > |         be attached as handlers using the Interrupts package, the
 > |         finalization discussed above occurs only as part of the finalization
 > |         of all library-level packages in a partition.
-> 
+>
 >    The 12.a annotation is partially incorrect since you can get
 > non-library level protected objects requiring such finalization by
 > declaring an object of a protected type with an Attach_Handler pragma.
 > (RM forbids only non-library level objects with a pragma
 > Interrupt_Handler in them.)
-> 
+>
 >    Is this intented? It forces implementation to keep somehow a stack
 > of "previous handlers" for non library-level PO with Attach_Handler,
 > that sounds very dynamic for a "static" feature (Attach_Handler needs
 > more dynamic work than Ada.Interrupt and Interrupt_Handler...).
-> 
-> -- 
+>
+> --
 > Laurent Guerby <guerby@gnat.com>, Team Ada.
 >    "Use the Source, Luke. The Source will be with you, always (GPL)."
 

Questions? Ask the ACAA Technical Agent