Re: Ada.Execution_Time

["(see below)" <news@findlayw.plus.com>]

On 29/12/2010 14:30, in article aooml6t0ezs4.4srxtfm9z00r.dlg@40tude.net,
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:

> On Wed, 29 Dec 2010 14:48:20 +0200, Niklas Holsti wrote:
> 
>> Dmitry has agreed with some of my statements on this point, for example:
>> 
>> - A task cannot accumulate execution time at a higher rate than real
>> time. For example, in one real-time second the CPU_Time of a task cannot
>> increase by more than one second.
> 
> Hold on, that is only true if a certain model of CPU_Time measurement used.
> There are many potential models. The one we discussed was the model A:
> 
> Model A. Get an RTC reading upon activation. Each time CPU_Time is
> requested by Clock get another RTC reading, build the difference, add the
> accumulator to the result. Upon task deactivation, get the difference and
> update the accumulator.
> 
> This is a very strong model. Weaker models:
> 
> Model A.1. Get RTC upon activation and deactivation. Update the accumulator
> upon deactivation. When the task is active CPU_Time does not change.
> 
> Model B. Use a time source different from RTC. This what Windows actually
> doest.
> 
> Model B.1. Like A.1, CPU_Time freezes when the task is active.
> 
> Model C. Asynchronous task monitoring process
> 
> ...
> Note that in either model the counter readings are rounded. ...
> 
>> - If only one task is executing on a processor, the execution time of
>> that task increases (or "could increase") at the same rate as real time.
> 
> This also may be wrong if a B model is used. ...
> 
>> The question is how much meaning should be read into ordinary words like
>> "time" when used in the RM without a formal definition.
> 
> Time as physical concept is not absolute. There is no *the* real time, but
> many real times and even more unreal ones.  ...

I hope we can agree that Ada is defined "sensibly".

From this I deduce that the intent for CPU_Time is that it be a useful
approximation to the sum of the durations (small "d") of the intervals of
local inertial-frame physical time in which the task is in the running
state.

It seems to me that the only grey area is the degree of approximation that
is acceptable for the result to be "useful".

Dmitri raises some devils-advocate issues around that. Some of them might be
considered to be dismissed by the assumption of sensible definition. Others
might not be so clear. Perhaps the ARG consider these to be issues of
implementation quality rather than semantics.

-- 
Bill Findlay
with blueyonder.co.uk;
use  surname & forename;