Re: An Example for Ada.Execution_Time

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

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
       .      @       .