CVS difference for ais/ai-00297.txt

Differences between 1.12 and version 1.13
Log of other versions for file ais/ai-00297.txt

--- ais/ai-00297.txt	2004/01/23 04:59:26	1.12
+++ ais/ai-00297.txt	2004/02/06 05:01:47	1.13
@@ -1419,3 +1419,512 @@
 
 ****************************************************************
 
+From: Alan Burns
+Sent: Wednesday, December 17, 2003  11:15 AM
+
+AI 297 was returned by WG9 to the ARG. I had not seen the
+email on this from Randy before traveling to San Diego.
+
+There were a number of wording comments, Randy dealt with some of
+these but felt I should look at a couple. First the meaning
+of the parameters to Set_Handler was not explicit. I've added
+a couple of sentances to Randy's new first paragraph of dynamic
+semantics - remember the model is that the event is set when a
+handler is registered.
+
+The other point concerned being explicit about the time at which
+the handler is executed. Randy felt reference to D.9 did not
+help. Also it was felt that saying handler executed after some defined time
+was not enough (ie no upper bound). I've looked at the words
+for delay statements and interestingly they do not give an upper
+bound either, but give a metric. So I've chosen to use the
+words suggested 'As soon as possible after' and added a metric,
+but removed reference to D.9.
+
+I've reordered a couple of other paragraphs to follow suggestion
+to use order in package to order these paragraphs.
+
+I'll give the wording section only as I hope those concerned
+with the wording of the AI can check that the changes are
+appropriate. It would be good if this can be done soon.
+Wording can then be placed back in the full AI (by Randy?)
+
+
+
+!wording
+
+Add new section D.15
+
+D.15 Timing Events
+
+This clause introduces a language-defined child package of Ada.Real_Time
+to allow user-defined protected procedures to be executed at a specified
+time without the need to use a task or a delay statement.
+
+Static Semantics
+
+The following language-defined package exists:
+
+package Ada.Real_Time.Timing_Events is
+  type Timing_Event is limited private;
+  type Timing_Event_Handler
+       is access protected procedure(Event : in out Timing_Event);
+  procedure Set_Handler(Event : in out Timing_Event;
+            At_Time : in Time; Handler: in Timing_Event_Handler);
+  procedure Set_Handler(Event : in out Timing_Event;
+            In_Time: in Time_Span; Handler: in Timing_Event_Handler);
+  function Is_Handler_Set(Event : Timing_Event) return Boolean;
+  function Current_Handler(Event : Timing_Event)
+           return Timing_Event_Handler;
+  procedure Cancel_Handler(Event : in out Timing_Event;
+            Cancelled : out Boolean);
+  function Time_Of_Event(Event : Timing_Event) return Time;
+private
+  ... -- not specified by the language
+end Ada.Real_Time.Timing_Events;
+
+An object of type Timing_Event is said to be set if it has a
+registered Timing_Event_Handler. An object is said to be cleared
+if it has no registered Timing_Event_Handler. All Timing_Event objects
+are initially cleared.
+
+Dynamic Semantics
+
+A call to a Set_Handler procedure returns after the Timing_Event_Handler
+denoted by Handler is registered. The first Set_Handler procedure
+registers the Timing_Event_Handler for execution at time At_Time.
+The second Set_Handler procedure registers the Timing_Event_Handler
+for execution at time Ada.Real_Time.Clock + In_Time;
+
+A call to a Set_Handler procedure for a Timing_Event that is already
+set will initially cancel the earlier registration.
+The Timing_Event denoted by Event remains set.
+
+A call of either Set_Handler procedure is not a potentially blocking
+operation.
+
+As soon as possible after the time registered for the event, the
+Timing_Event_Handler procedure is executed. The Timing_Event_Handler
+is only executed if the timing event is set at the time of execution.
+As the initial action of the execution of the Timing_Event_Handler
+the Timing_Event denoted by Event is cleared.
+
+If the Ceiling_Locking policy (see D.3) is in effect when a Set_Handler
+procedure is called, a check is made that the ceiling priority of
+Timing_Event_Handler is Interrupt_Priority'last. If the check fails,
+Program_Error is raised.
+
+If a Set_Handler procedure is called with zero or negative In_Time or with
+At_Time indicating a time in the past then Timing_Event_Handler is
+executed immediately by the task executing the Set_Handler call.
+The Timing_Event denoted by Event is cleared and the handler is not
+registered.
+
+An exception propagated from a Timing_Event_Handler invoked by
+a timing event has no effect.
+
+A call to Is_Handler_Set returns True if Event is set;
+otherwise it returns False.
+
+A call to Current_Handler returns with the current Timing_Event_Handler.
+If the Timing_Event denoted by Event is not set, Current_Handler returns
+null.
+
+A call to Cancel_Handler returns after the Timing_Event denoted by Event
+is cleared. Cancelled is assigned True if Event was set prior to it
+being cleared; otherwise the parameter is assigned False.
+
+A call to Time_Of_Event returns with the time of Event.
+If Event is not set, Time_Of_Event returns Ada.Real_Time.Time_First.
+
+As the final step of finalization of an object of type Timing_Event,
+the Timing_Event is cleared.
+
+If several timing events are registered for the same time,
+they are executed in FIFO order of registration.
+
+Metrics
+The Implementation shall document the following metric:
+  An upper bound on the lateness of the execution of a registered handler.
+  That is, the maximum time between when a handler is actually executed
+  and the time specified in the registration of that handler.
+
+Implementation Advice
+The protected handler procedure should be executed directly by the
+real-time clock interrupt mechanism.
+
+Notes
+Since a call to Set_Handling is a not a blocking operation, it can be
+called from within an object of type Timing_Event_Handler.
+
+Add to D.7 a new restriction identifier
+
+No_Local_Timing_Events
+	Timing_Events shall be declared only at library level.
+
+Add this restriction to the Ravenscar definition (D.13).
+
+****************************************************************
+
+From: Robert A. Duff
+Sent: Wednesday, December 17, 2003  2:20 PM
+
+> The other point concerned being explicit about the time at which
+> the handler is executed. Randy felt reference to D.9 did not
+> help. Also it was felt that saying handler executed after some defined time
+> was not enough (ie no upper bound). I've looked at the words
+> for delay statements and interestingly they do not give an upper
+> bound either, but give a metric. So I've chosen to use the
+> words suggested 'As soon as possible after' and added a metric,
+> but removed reference to D.9.
+
+I think you had it right the first time.  Those "metrics" are completely
+meaningless, yet they pretend to be requiring something of the
+implementation.  Useless verbiage.  The better way to express this sort
+of thing is with Implementation Advice (which you did).
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, December 17, 2003  5:05 PM
+
+> ... Those "metrics" are completely
+> meaningless, yet they pretend to be requiring something of the
+> implementation.  Useless verbiage.
+
+I'm not sure I agree.  It seems clear that in the real-time
+community, you really do want the vendor to provide
+metrics (or at least feel a bit guilty if they don't).
+
+> ... The better way to express this sort
+> of thing is with Implementation Advice (which you did).
+
+Implementation advice is also useful, but clearly serves
+a somewhat different purpose.  Neither has any real weight.
+Both can be useful in establishing some "norms."
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, December 17, 2003  11:15 AM
+
+Tucker Taft wrote:
+
+>>... Those "metrics" are completely
+>>meaningless, yet they pretend to be requiring something of the
+>>implementation.  Useless verbiage.
+>
+>
+> I'm not sure I agree.  It seems clear that in the real-time
+> community, you really do want the vendor to provide
+> metrics (or at least feel a bit guilty if they don't).
+
+As normative requirements, these are complete junk, since
+they do not define the form or requirements sufficiently
+well and use undefined terms.
+
+>>... The better way to express this sort
+>>of thing is with Implementation Advice (which you did).
+>
+> Implementation advice is also useful, but clearly serves
+> a somewhat different purpose.  Neither has any real weight.
+> Both can be useful in establishing some "norms."
+
+I actually think that implementation advice ends up being
+stronger here. First, we can say what we want, without
+worrying whether it has formal semantic meaning. Second,
+we expect at least documentation of what is not supported
+in IA (and I think it would be reasonable to require
+the reason for not following any IA in the documentation).
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, December 18, 2003  9:18 AM
+
+In the spirit of talking with "real users", perhaps we should
+ask the real-time user community rather than vendors whether these
+"documentation requirements" have turned out to be of any use.
+I personally have no idea.
+
+The value of implementation advice seems to be in its guidance
+to implementors and in its documentation requirement.
+It would seem that metrics have exactly the same
+value, namely guidance in the sense of what time bounds are relevant
+to customers, and documentation requirements in terms of what numbers
+to provide (and perhaps the process of getting them is also
+useful activity).
+
+The question is which documentation is actually provided by
+vendors, and then which documentation is actually of value to users.
+
+My hope is that both are provided, and both are of value.
+But I have been known to be an optimist ;-).
+
+****************************************************************
+
+From: Robert A. Duff
+Sent: Thursday, December 18, 2003  12:04 PM
+
+> In the spirit of talking with "real users", perhaps we should
+> ask the real-time user community rather than vendors whether these
+> "documentation requirements" have turned out to be of any use.
+> I personally have no idea.
+
+That's certainly a good idea, but one of the things I don't like about
+the Metrics is that because of their style, they might trick
+non-language-lawyers into thinking they actually formally *require*
+something.  We might find programmers who say, "of course we want to
+know about interrupt-handling overhead", but if that information is
+bogus, well, ...
+
+It seems to me that Implementation Advice along the lines of "... should
+take a small and bounded amount of time" would be more informative.
+
+As *requirements*, the Metrics are silly.  Real-time programmers use
+integer addition more often than they use delay statements, and they
+want bounded-time integer addition.  So why don't we have Metrics about
+integer addition?  If we didn't pretend they were requirements, it would
+make more sense -- we trust compiler writers and programmers to know
+what's obvious.
+
+> The value of implementation advice seems to be in its guidance
+> to implementors and in its documentation requirement.
+
+Also, they let programmers know what to expect of implementations.
+It may be that two different implementation strategies have wildly
+different efficiency properties, but neither is uniformly better.
+With IA, we can encourage some uniformity across implementations
+(which is what standards are for!) and we can let programmers know
+what to expect.
+
+****************************************************************
+
+From: Alan Burns
+Sent: Friday, December 19, 2003  5:28 AM
+
+> As *requirements*, the Metrics are silly.  Real-time programmers use
+> integer addition more often than they use delay statements, and they
+> want bounded-time integer addition.  So why don't we have Metrics about
+> integer addition?  If we didn't pretend they were requirements, it would
+> make more sense -- we trust compiler writers and programmers to know
+> what's obvious.
+
+Yes this sums up some of the discussions that occured at IRTAW
+during Ada95 process. Some people felt that metrics were key,
+others felt that they could never give the full story and that
+discussions with the complier vendor would always be needed to
+get the implementation model and parameters defined (if detailed
+timing analysis was needed). So one of the points of the metrics
+became to focus implementers on potential inefficiencies. Most
+metrics identify some parameter that we would like to see be as
+small as possible.
+
+In discussions on Ravenscar, the IRTAW decided not to give a whole
+load of new metrics; rather it decided to add discussion on metrics
+etc in the Guide (being produced by HRG) on Ravenscar.
+
+Returning to Timing Events. The point of the metric or IA is to
+make it clear that is would not be acceptable for an implementation
+to fire a timing event 10 years/months/days/mintues/seconds after the
+time specified. A secondard point is to find out what the maximum
+lateness is. In practice no new metric is needed as the same
+mechanism/accurancy for delay statements will be used for timing
+events.
+
+So do I stay with the metric, or have IA such as 'The implementation
+shall fire any timing event as soon as possible after the time
+specified in its registration.'?
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, December 19, 2003  7:53 AM
+
+I would recommend you follow the lead of other sections of
+the real-time systems annex (e.g. D.8) and use a mixture
+of Implementation Advice for largely non-quantitative
+issues and Metrics for largely quantitative issues.
+
+****************************************************************
+
+From: Robert A. Duff
+Sent: Friday, December 19, 2003  9:37 AM
+
+Alan said:
+
+> Returning to Timing Events. The point of the metric or IA is to
+> make it clear that is would not be acceptable for an implementation
+> to fire a timing event 10 years/months/days/mintues/seconds after the
+> time specified.
+
+Well, I've implemented delay statements in both Ada 83 (before metrics)
+and Ada 95.  I didn't actually *need* to be told that "10 seconds late
+is too late".  I figured that out on my own.
+
+Sometimes it seems like people think that compiler vendors are liable to
+go around deliberately sabotaging their own products if the Standard
+doesn't prevent it!  ;-)
+
+> So do I stay with the metric, or have IA such as 'The implementation
+> shall fire any timing event as soon as possible after the time
+> specified in its registration.'?
+
+Well, I guess WG9 wants a metric, so the expedient thing is to put in a
+metric.  It's not your job to keep Bob Duff happy.  ;-)
+
+****************************************************************
+
+From: Ben Brosgol
+Sent: Friday, December 19, 2003  10:50 AM
+
+> Sometimes it seems like people think that compiler vendors are liable to
+> go around deliberately sabotaging their own products if the Standard
+> doesn't prevent it!  ;-)
+
+Wasn't there an early Ada 83 compiler that had not yet implemented
+preemption so its implementation of the delay statement was to suspend
+the task forever?  It satisfied the semantics of the RM ("suspends
+further execution ... for at least the duration specified ...")
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, December 19, 2003   3:27 PM
+
+I believe this is urban legend. At one ARG meeting, one Robert Dewar
+noted that such an implementation would be compliant. Someone commented
+that perhaps that was a desirable implementation for nuclear missile
+control programs :-) :-)
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Saturday, December 20, 2003   5:30 AM
+
+As far as I remember, this was the first version of the Meridian compiler. I
+remember a big argument at that time, and that Meridian eventually redid its
+scheduling.
+
+****************************************************************
+
+From: Dan Eilers
+Sent: Friday, December 19, 2003  11:16 AM
+
+> So do I stay with the metric, or have IA such as 'The implementation
+> shall fire any timing event as soon as possible after the time
+> specified in its registration.'?
+
+My 2 cents worth is to go very sparingly on documentation of timing
+issues in normative parts of the RM.  Compilers are often developed
+using instruction-level simulators, or prototype development boards,
+that are substantially different from the end-user's target hardware
+with respect to clock speeds, cache sizes and speeds, main memory
+sizes and speeds, availability of hardware timers, contention from
+other processors, load on the system, etc.
+
+So the implementer can address qualitative issues such as whether
+the runtime system supports task preemption, but not necessarily the
+number of microseconds or even clock cycles that something will take.
+
+In some cases, it would be better to provide constants and/or
+attributes that can be queried by the software, e.g., system.tick,
+so that the answers provided are more likely to be correct than
+documentation which can easily be out-of-date, or created for a
+somewhat different target environment, or mistakenly calculated,
+or completely missing.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, December 19, 2003  11:46 AM
+
+burns@cs.york.ac.uk wrote:
+
+> Returning to Timing Events. The point of the metric or IA is to
+> make it clear that is would not be acceptable for an implementation
+> to fire a timing event 10 years/months/days/mintues/seconds after the
+> time specified. A secondard point is to find out what the maximum
+> lateness is. In practice no new metric is needed as the same
+> mechanism/accurancy for delay statements will be used for timing
+> events.
+
+This seems misguided to me. An implementation is free to generate
+code that takes ten years to do each addition, and we don't worry
+ourselves about that.
+
+The proper way to approach this is to have implementation advice
+suggesting what sort of implementations are appropriate (e.g.
+abort is expected to be "immediate" not to wait for a synchonization
+point.
+
+Note one point that the current metrics are inconsistent. Some
+call for guaranteed lower bounds (something that is typically
+impossible to give in most real life real time envirtonments,
+since there are far too many layers to analyze when running
+on top of operating systems, and the hardware is too hard to
+analyze in any case, e.g. cache and TLB effects).
+
+Other metrics ask essentially for the output of a test program.
+That's really silly, it simply mandates that a benchmark be
+written, and its results published with no idea of exactly
+how they were measured. It would be better to spend the
+effort on generating standard benchmark programs!
+
+But if nonsense metric requirements make people happy fine, put
+them in, they are relatively harmless, since mostly they get
+ignored.
+
+And no, we don't feel bad about ignoring them, since they are
+documentation requirements, they are completely undefined in
+my view anyway, and when it comes to documentation, we are
+oriented to providing what our customers find useful, the
+RM is really somewhat irrelevant.
+
+We have seen neither customer demand in the metrics area, nor
+competitive pressure ("buy XYZ Ada compiler, unlike GNAT it has
+proper metrics :-)
+
+****************************************************************
+
+From: Robert I. Eachus
+Sent: Friday, December 19, 2003  10:59 PM
+
+>So do I stay with the metric, or have IA such as 'The implementation
+>shall fire any timing event as soon as possible after the time
+>specified in its registration.'?
+
+I always figure that it was one of my comments on the draft RM in 1982
+that resulted in the current wording.  I noticed that the then current
+text was incorrect.  It didn't allow for the possibility that a higher
+priority task was executing when a delay expired.  Jean thought my
+suggested wording was ugly, and came up with wording that looked
+innocuous enough.  But if I had known the amount of FUD it would
+generate, I would still have been screaming about it.
+
+There were words elsewhere on which tasks were eligible to run at any
+point in time.  Jean thought that was sufficient to guarentee that a
+task would be scheduled immediately on the expiration of a delay, unless
+there was at least one higher priority task running.  Instead, that
+wording resulted in a lot of bogus tests to check that the delay was
+never rounded down--and a lot of FUD like the idea that a task whose
+delay expired need not ever be scheduled to run.  (True, but only if
+there was always at least one equal or higher priority task eligible to
+run.)
+
+****************************************************************
+
+From: Alan Burns
+Sent: Saturday, December 27, 2003  8:04 AM
+
+There were a round of emails on this topic but no clear conclusion
+on whether there should be a Metric or IA. I have no strong view
+either. The wording I sent used a metric - so Randy could you
+put the new wording into a new version of the AI (only wording
+should be changed) and either stay with the metric or change to
+AI if you feel that would be better. I'm on vacation for the
+next 3 weeks, so please excuse silence if there is another round
+of discussions.
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent