Re: Ada.Execution_Time

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Sat, 25 Dec 2010 13:31:27 +0200, Niklas Holsti wrote:

> 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,
> ... ?

Applicability of a concept is not what makes it wrong or right.

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

Why? Scheduling does not need Ada.Execution_Time, it is the
Ada.Execution_Time implementation, which needs some input from the
scheduler.

How do you explain that CPU_Time, a thing about time sharing, appears in
the real-time systems annex D?

> You have
> not given any arguments, based on the RM text, to support your position.

I am not a language lawyer to interpret the RM texts. My argument was to
common sense.

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

Nope, one of the killer arguments ARG people deploy to reject most
reasonable AI's is: too difficult to implement on some obscure platform for
which Ada never existed and never will. (:-))

> As 
> already said, an Ada implementation on such CPU/OS could use its own 
> mechanisms for execution-time measurements.

Could or must? Does GNAT this?

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

If that was the intent, then I really do not understand why CPU_Time was
introduced in addition to Ada.Real_Time.Time / Time_Span.

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

Simulation time is a model of real time a physical process might have under
certain conditions.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de