CVS difference for ais/ai-00357.txt
--- ais/ai-00357.txt 2003/11/25 02:23:38 1.3
+++ ais/ai-00357.txt 2003/12/07 05:00:33 1.4
@@ -2228,7 +2228,7 @@
****************************************************************
From: Robert Dewar
-Sent: Wednesday, November 24, 2003 6:55 AM
+Sent: Monday, November 24, 2003 6:55 AM
what concerns me about this series of proposals for language additions from
Alan is that they have the feeling of "let's design some nice new features",
@@ -2246,7 +2246,7 @@
****************************************************************
From: Tucker Taft
-Sent: Wednesday, November 24, 2003 7:35 AM
+Sent: Monday, November 24, 2003 7:35 AM
I believe all of these grew out of the Int'l Real-Time Ada Workshop.
My sense is that many of the attendees are "real" users of Ada,
@@ -2257,7 +2257,7 @@
****************************************************************
From: Tullio Vardanega
-Sent: Wednesday, November 24, 2003 7:53 AM
+Sent: Monday, November 24, 2003 7:53 AM
Yes, the whole range of real-time AIs have been conceived at
and pushed for by the IRTAW, prior to, during and subsequent
@@ -2283,7 +2283,7 @@
****************************************************************
From: Robert Dewar
-Sent: Wednesday, November 24, 2003 8:13 AM
+Sent: Monday, November 24, 2003 8:13 AM
Right, I understand this, but it is still very important to differentiate
between nice-to-have, and missing-essential-functionality (some things are
@@ -2294,7 +2294,7 @@
****************************************************************
From: Robert Dewar
-Sent: Wednesday, November 24, 2003 8:17 AM
+Sent: Monday, November 24, 2003 8:17 AM
> which -- just seen from
> the stream of AIs that Alan just posted -- seem to extoll a major
@@ -2317,7 +2317,7 @@
****************************************************************
From: Alan Burns
-Sent: Wednesday, November 24, 2003 10:26 AM
+Sent: Monday, November 24, 2003 10:26 AM
Re the comments and concerns raised by Robert.
@@ -2379,7 +2379,7 @@
****************************************************************
From: Randy Brukardt
-Sent: Wednesday, November 24, 2003 7:30 PM
+Sent: Monday, November 24, 2003 7:30 PM
Alan said:
@@ -2419,6 +2419,61 @@
In any case, I tend to share Robert's skepticism about the demand for some
of these proposals. I, like him, hope to be proven wrong.
+
+****************************************************************
+
+From: Alan Burns
+Sent: Tuesday, November 25, 2003 2:53 AM
+
+>...
+>
+>> OSs in the high integrity area all monitor (in some
+>> form or other) CPU usage as an error recognition facility.
+> ...
+>
+> CPU usage is important to improving the performance of any Ada program, not
+> just real time ones. (If you can't measure it, you can't improve it!). It's
+> unfortunate that the package has evolved such that budgeting is given
+> priority over measurement. Clearly, both have value (and proposals having
+> value for multiple purposes should be preferred over those having value for
+> only one purpose).
+
+The execution time clocks AI is all about measurement, indeed
+one of its main uses will be to measure task execution times.
+It has this multiple purpose (measurement alone or measurement
+and budgeting).
+
+>> 4. Support for recognition of task termination (AI10266).
+>> I picked this up as it gave out of the Ravenscar AI. It is
+>> not a high priority; but other groups have asked for this
+>> (eg the workshop on exception handling a couple of years ago).
+>
+> It's interesting that the capability that seems most important from a High
+> Integrity perspective (insuring that parts of the system don't become
+> inoperative without notice) is considered to have the lowest priority.
+> Certainly, this is the problem that I run into in practice (tasks going away
+> silently when the task's others exception handler either is absent, has a
+> bug, or exhausts the same resource).
+
+Remember that a very simple scheme was deemed adequate for Ravenscar,
+and there are other approaches with full Ada. My point was that an
+Alan AI does not mean its an AI from IRTAW.
+
+> In any case, I tend to share Robert's skepticism about the demand for some
+> of these proposals. I, like him, hope to be proven wrong.
+
+I will not repeat the points I made in previous email. But note the most
+recent attempt to define/design language features for a real-time
+language (real-time Java) attempts to have all these features and
+more. I say attempt because I do not think the features are as well
+thought out as these Ada proposals.
+
+Also most of these feature are low overhead (eg additional run-time
+packages) that, as Robert says, do not need to be supported until
+customers need them. But if implemented, the RM defines a standard
+way. The fact that Ada supports them makes a strong statement about
+the language. Control over execution time and the introduction of
+the notion of 'deadline' is not I believe excessive.
****************************************************************
Questions? Ask the ACAA Technical Agent