From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,61d8daec8bfa486e X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news2.google.com!news.glorb.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: An Example for Ada.Execution_Time Date: Sat, 01 Jan 2011 22:25:30 +0200 Organization: Tidorum Ltd Message-ID: <8o9gtqFbuvU1@mid.individual.net> References: <1fb06tjt2dy1y$.1tkafcv9oya2w.dlg@40tude.net> <8o61e2FkdvU1@mid.individual.net> <1jmysfv0ifrrj$.h84gfj1gv0ht.dlg@40tude.net> <8o6ndjFm6sU1@mid.individual.net> <4tsecsvlsdzx$.8w12tfj8af75.dlg@40tude.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net Qz+1GczLAHg9Z7hqbXuVRwmvZixFopFuV1VCHb4VfJb8eXSJQz Cancel-Lock: sha1:kCBx1zfkGbfWmNTtpMkdMFKpGAQ= User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100328) In-Reply-To: <4tsecsvlsdzx$.8w12tfj8af75.dlg@40tude.net> Xref: g2news2.google.com comp.lang.ada:17271 Date: 2011-01-01T22:25:30+02:00 List-Id: Dmitry A. Kazakov wrote: > On Fri, 31 Dec 2010 20:57:54 +0200, Niklas Holsti wrote: > >> Dmitry A. Kazakov wrote: >>> On Fri, 31 Dec 2010 14:42:41 +0200, Niklas Holsti wrote: >>> >>>> Dmitry A. Kazakov wrote: >>>>> On Thu, 30 Dec 2010 18:51:30 -0500, BrianG wrote: >>>>> >>>>>> Since D.16 defines CPU_Time as if it were a numeric value, is it too >>>>>> much to ask why a conversion to some form of numeric value wasn't >>>>>> provided? >>>>> But time is not a number and was not defined as if it were. >>>> You keep saying that, Dmitri, but your only argument seems to be the >>>> absence of some operators like addition for CPU_Time. Since CPU_Time is >>>> private, we cannot tell if this absence means that the D.14 authors >>>> considered the type non-numeric, or just considered the operators >>>> unnecessary for the intended uses. >>> No, the argument is that time is a state of some recurrent process, like >>> the position of an Earth's meridian relatively to the Sun. This state is >>> not numeric, it could be numeric though. That depends on the nature of the >>> process. >> This is your view of what the English word "time" means. > > The English word "time" it has many meanings. Yes indeed.... Dmitry, I think we are arguing this point -- whether Ada.Execution_Time.CPU_Time has "numeric" values -- from different personal definitions of what "numeric" means, so we are not going to agree, and should stop. Meanwhile, I was reminded that the Ada RM actually defines "numeric type" as an integer or real type (RM 3.5(1)). Since CPU_Time and Time_Span etc. are all private types, and the RM does not say if they are implemented as integer or real types, we cannot know if they are "numeric types" using RM terms. Let's stop here, OK? > It is based on the fact that RM always introduces a distinct type, when it > means duration, time interval, period, e.g.: Duration, Time_Span. When RM > uses a type named "time," it does not mean duration. Yes, I agree that this is the RM principle, but I also think it is a different question. You may remember that Randy said that the ARG had discussions about type names for Ada.Execution_Time, and were not very happy with the name "CPU_Time" (as I understood Randy, at least). Note that RM D.14 does not say that CPU_Time is a "time type" as "time types" are defined in RM 9.6. In contrast, Ada.Real_Time.Time is a "time type". > D.14 reuses Time_Span for > intervals of CPU_Time, which stresses the difference. If this is not clean, > then, not because CPU_Time is duration, it is because CPU_Time can be (and > is) unrelated to the source of Ada.Real_Time.Time. I definitely don't agree that CPU_Time can be unrelated to the source of Ada.Real_Time.Time in an Ada system that is useful for real-time programming. Execution time may be measured with a different clock or timer than Ada.Real_Time.Time but the rates of the two times must be very closely the same while one task is executing. Otherwise Ada.Execution_Time would be useless. Perhaps you mean that CPU_Time is unrelated to Ada.Real_Time.Time over longer periods during which the task is sometimes executing, sometimes not. Then I agree that the two times increase at different rates, of course. > Thus reusing Time_Span for its intervals questionable. It would > be better to introduce a separate type for this, e.g. CPU_Time_Interval. I strongly disagree, because that would abandon the commensurability of CPU_Time (or its intervals) with real time and would destroy the usefulness of Ada.Execution_Time in real-time systems. > Furthermore, the CPU_Time type should be local to the task, It could be reasonable to have different CPU_Time types for each task. I can't immediately think of any reason for comparing or subtracting CPU_Time values across tasks. But I don't think this can be implemented in Ada. > preventing its usage anywhere outside the task, This would prevent or hamper the implementation of scheduling algorithms that monitor the execution times of several tasks. I object to it. > while CPU_Time_Interval could be same for all tasks. Definitely. And it must be the same as Ada.Real_Time.Time_Span or Duration for real-time scheduling purposes. > RM is consistent here, but, as I said, sloppy, because the zero element of > a time system has a specific name: "epoch." RM uses this term in D.8, so > should it do here. Manfully resisting the strong temptation to continue to argue about the "numeric" issue, based on your statements about "zero", I want to comment on this "epoch" thing. One of the differences between Ada.Real_Time.Time and Ada.Execution_Time.CPU_Time is that the epoch for the former is not specified in the RM. It follows that even if Ada.Real_Time.Time had a visibly numeric value, its meaning would be unknown to the program. In contrast, the epoch for CPU_Time is specified in the RM: the creation of the task, a point in real time known to the program. This brings CPU_Time closer to the meaning of Duration or Time_Span. If CPU_Time had a visibly numeric value, its meaning would be known: the total execution time of the task since the program created the task. I think the main reason why RM D.14 defines a specific type CPU_Time, instead of directly using Duration or Time_Span, is the large range required of CPU_Time: up to 50 years. Time_Span is required to hold only +- 1 hour, and Duration only +- 1 day. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .