CVS difference for ai05s/ai05-0170-1.txt

Differences between 1.5 and version 1.6
Log of other versions for file ai05s/ai05-0170-1.txt

--- ai05s/ai05-0170-1.txt	2010/08/21 02:54:01	1.5
+++ ai05s/ai05-0170-1.txt	2010/10/19 03:51:18	1.6
@@ -1,4 +1,4 @@
-!standard  D.14(9/2)                                10-08-09    AI05-0170-1/04
+!standard  D.14(9/2)                                10-10-07    AI05-0170-1/05
 !standard  D.14(11/2)
 !standard  D.14(13/2)
 !standard  D.14(18/2)
@@ -14,11 +14,8 @@
 
 !summary
 
-Ada 2005 defines execution time clocks and timers for tasks, and
-leaves the accounting of the execution time of interrupts as
-implementation-defined. Implementation advice is provided to enhance
-execution time clocks and timers by appropriately accounting for
-execution time of interrupts when possible on the underlying platform.
+Facilities are added to enable the time spent in interrupt handlers to be 
+accounted for separately from time spent in tasks.
 
 !problem
 
@@ -42,10 +39,10 @@
 interrupt handlers on the execution time clocks is negligible since
 the interrupt handlers are usually very sort pieces of code. However,
 in real-time systems that undertake an intensive use of interrupts this
-assumption may not be realistic. For example, Ada 2005 has introduced
+assumption may not be realistic. For example, Ada 2005 introduced
 timed events that can execute handlers in interrupt context. The
 facility is convenient and has low overheads, and therefore
-programmers are tempted to putting more code into these handlers.
+programmers are tempted to put more code into these handlers.
 
 As is shown in two papers at the 14th IRTAW it is possible with moderate
 effort to monitor and manage the execution time of interrupt handlers
@@ -53,27 +50,19 @@
 Execution Time Clocks provide a more realistic value of the time a
 task has executed and, what is more important, execution time overruns
 detected using Execution Time Timers and Group Execution Time Budgets
-are more accurate. Therefore the first part of this proposal is to add
-in the Ada standard implementation advice that will guide
-implementors on the approach that is considered more adequate to reach
-the needs of real-time applications.
+are more accurate. Therefore, the proposal rewords the definition of
+execution time to make it clear that the execution time of interrupts
+can be accounted for separately.
 
 If execution time of interrupts is monitored separately from that of
 the tasks, it is easy to make the accounting of these execution times
 available to the application. This information is useful to real-time
-analysis and, therefore, the second part of this proposal is to add
-facilities to allow the application to obtain the execution time of
-interrupts.
-
-Once execution time accounting is made for interrupts, it is not
-difficult to also provide facilities to notify about execution time
-overruns by interrupt service routines. These are useful to detect
-timing violations inside interrupt code. This is the third part of our
-proposal.
+analysis; therefore this proposal adds facilities to allow the
+application to obtain the execution time of interrupts.
 
 !proposal
 
-See wording and discussion.
+(See wording.)
 
 !wording
 
@@ -86,8 +75,8 @@
 
 function Clock_For_Interrupts return CPU_Time;
 
+Replace D.14(11/2) with:
 
-Change 11/2 to:
 The execution time or CPU time of a given task is defined as the time spent
 by the system executing that task, including the time spent executing run-time
 or system services on its behalf. The mechanism used to measure execution time
@@ -100,10 +89,10 @@
 individual interrupt handlers.
 
 Add to end of D.14(13/2):
-The execution time value for the Clock_For_Interrupts is initialized to zero.
 
+The execution time value for the function Clock_For_Interrupts is initialized
+to zero.
 
-
 Add to after D.14(18/2):
 
 The function Clock_For_Interrupts returns the total cumulative time spent
@@ -112,7 +101,6 @@
 the function raises Program_Error.
 
 
-
 Add a new D.14.3
 
 Execution Time of Interrupt Handlers
@@ -139,7 +127,7 @@
 Time spent executing interrupt handlers is distinct from time spent
 executing any task.
 
-For each interrupt ID, the execution time value is initially set to zero.
+For each interrupt, the execution time value is initially set to zero.
 
 
 Dynamic Semantics
@@ -148,36 +136,24 @@
 interrupt identified by I. If Separate_Interrupt_Clocks_Supported is
 set to False the function raises Program_Error.
 
-
 The function Supported returns True if the implementation is monitoring
-the execution time of interrupt I. Otherwise it returns False. For any
-interrupt ID I for which Supported(I) returns False, the function Clock(I)
-will return a value equal to Ada.Execution_Time.Time_Of(0).
+the execution time of the interrupt identified by I. Otherwise it returns
+False. For any interrupt_Id I for which Supported(I) returns False, the
+function Clock(I) will return a value equal to Ada.Execution_Time.Time_Of(0).
 
 
 !discussion
 
-This AI contains a proposal to add to the Ada standard
-implementation advice on how to handle the measurement of the
-execution time of interrupt handlers separately from the execution
-time of user tasks.
-
-The most interesting aspect of the new service is that it can
+This AI allows the measurement of the execution time of interrupt handlers
+separately from the execution time of user tasks. Doing so can
 significantly enhance the accuracy of the execution time clocks and
 timers of user tasks, because they are not arbitrarily charged with
 the execution times of interrupt service handlers.
 
-This support for managing the execution time of interrupt handlers
-does not require any language modification or the addition of any new
-API. However, once the interrupt execution time is measured, it can be
-made available to Ada applications via special clocks that
-measure the execution time of the interrupt handlers associated with a
-given interrupt Id.
-
-Moreover, it is possible to extend the current execution time timers
-to use the newly defined execution time clocks for interrupt handlers,
-thus introducing the ability for the system to detect execution time
-violations in interrupt handlers.
+Allowing separate measurement of the execution time of interrupt handlers
+does not require the addition of any new API. However, once the interrupt
+execution time is measured, it ought to be made available to Ada applications,
+so new facilities are needed for that purpose.
 
 Since all this functionality may not be available on all platforms,
 we also provide the ability to test whether it is present.
@@ -206,8 +182,9 @@
 supported. Such a program will need to with the new package, and
 that requires it exists even if it is not usefully implemented.
 
-The third part of the original proposal was dropped, as it seems
-to add overhead to interrupt handlers even when not used.
+The third part of the original proposal (to allow notification of
+execution time overruns in interrupt handlers) was dropped, as it
+seems to add overhead to interrupt handlers even when not used.
 
 
 The original IRTAW Proposal follows:
@@ -318,8 +295,6 @@
 
 !example
 
-** TBD **
-
 !corrigendum D.14(9/2)
 
 @dinsa
@@ -338,7 +313,7 @@
 
 @drepl
 The @i<execution time> or CPU time of a given task is defined as the time spent
-the system executing that task, including the time spent executing run-time or
+by the system executing that task, including the time spent executing run-time or
 system services on its behalf. The mechanism used to measure execution time is
 implementation defined. It is implementation defined which task, if any, is
 charged the execution time that is consumed by interrupt handlers and run-time
@@ -362,13 +337,14 @@
 CPU_Time_First and CPU_Time_Last are the smallest
 and largest values of the CPU_Time type, respectively.
 @dinst
-The execution time value for the Clock_For_Interrupts is initialized to zero.
+The execution time value for the function Clock_For_Interrupts is initialized
+to zero.
 
 
 !corrigendum D.14(18/2)
 
 @dinsa
-The effects of the Split and Time_Of operations are
+The effects of the Split and Time_Of operations are defined as
 follows, treating values of type CPU_Time, Time_Span, and
 Seconds_Count as mathematical integers. The effect of Split (T, SC,
 TS) is to set SC and TS to values such that T*CPU_Time_Unit = SC*1.0 +
@@ -408,7 +384,7 @@
 Time spent executing interrupt handlers is distinct from time spent
 executing any task.
 
-For each interrupt ID, the execution time value is initially set to zero.
+For each interrupt, the execution time value is initially set to zero.
 
 @s8<@i<Dynamic Semantics>>
 
@@ -417,8 +393,8 @@
 set to False the function raises Program_Error.
 
 The function Supported returns True if the implementation is monitoring
-the execution time of interrupt I. Otherwise it returns False. For any
-interrupt ID I for which Supported(I) returns False, the function Clock(I)
+the execution time of the interrupt identified by I. Otherwise it returns False.
+For any interrupt_Id I for which Supported(I) returns False, the function Clock(I)
 will return a value equal to Ada.Execution_Time.Time_Of(0).
 
 

Questions? Ask the ACAA Technical Agent