Re: Ada.Execution_Time

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

Dmitry A. Kazakov wrote:
> On Sat, 18 Dec 2010 23:20:20 +0200, Niklas Holsti wrote:
...
>> The concept and measurement of "the execution time of a task" does
>> become problematic in complex processors that have hardware 
>> multi-threading and can run several tasks in more or less parallel
>> fashion, without completely isolating the tasks from each other.
> 
> No, the concept is just fine,

Fine for what? For schedulability analysis, fine for on-line scheduling,
... ?

However, this is a side issue, since we are (or at least I am)
discussing what the RM intends with Ada.Execution_Time, which must be
read in the context of D.2.1, which assumes that there is a clearly
defined set of "processors" and each processor executes exactly one
task at a time.

> it is the interpretation of the measured values in the way you
> wanted, which causes problems. That is the core of my point. The
> measure is not real time.

I still disagree, if we are talking about the intent of the RM. You have
not given any arguments, based on the RM text, to support your position.

>>> I am not a language lawyer, but I bet that an implementation of 
>>> Ada.Execution_Time.Split that ignores any CPU frequency changes
>>> when summing up processor ticks consumed by the task would be
>>> legal.
>> Whether or not such an implementation is formally legal, that would
>> require very perverse interpretations of the text in RM D.14.
> 
> RM D.14 defines CPU_Tick constant, of which physical equivalent (if
> we tried to enforce your interpretation) is not constant for many
> CPU/OS combinations.

The behaviour of some CPU/OS is irrelevant to the intent of the RM. As 
already said, an Ada implementation on such CPU/OS could use its own 
mechanisms for execution-time measurements.

> On a such platform the implementation would be as perverse as RM D.14
> is. But the perversion is only because of the interpretation.

Bah. I think that when RM D.14 says "time", it really means time. You
think it means something else, perhaps a CPU cycle count. I think the 
burden of proof is on you.

It seems evident to me that the text in D.14 must be interpreted using
the concepts in D.2.1, "The Task Dispatching Model", which clearly
specifies real-time points when a processor starts to execute a task and
stops executing a task. To me, and I believe to most readers of the RM,
the execution time of a task is the sum of these time slices, thus a
physical, real time.

>> (In fact, some variable-frequency scheduling methods may prefer to
>> measure task "execution times" in units of processor ticks, not in
>> real-time units like seconds.)
> 
> Exactly. As a simulation time RM D.14 is perfectly OK.

I put my comment, above, in parentheses because it is a side issue.

And you still have not defined what you mean by "simulation time", and
how you come there from the RM text.

> It can be used for CPU load estimations,

How, if it has "no physical meaning", as you claim?

> while the "real time" implementation could not.

Why not? That is the way ordinary schedulability analysis works. And
again, it is irrevelant that some CPU/OS do not provide a good way to
measure the physical execution time of tasks.

> BTW, even for measurements people usually have in mind (e.g.
> comparing resources consumed by tasks), simulation time would be more
> fair.

What is "simulation time"?

> The problem is with I/O, because I/O is a "real" thing.

I assume by "I/O" you mean time consumed in waiting for some external
event. I agree that such I/O is a (solvable) problem in schedulability 
analysis, but it is not relevant for understanding the intent of RM D.14.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .