Re: Ada.Execution_Time

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

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. Windows rounds
toward zero, which why you never get more load than 100%. But it is
thinkable and expectable that some systems would round away from zero or to
the nearest bound. So the statement holds only if you have A (maybe C) + a
corresponding rounding.

> - 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. In particular, task switching
may be (and I think is) driven by the programmable timer interrupts. The
real-time clock may be driven by the TSC. Since these two are physically
different, unsynchronized time sources, the effect can be any. It is to
expect a systematic error accumulated with the time.

> 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 don't think RM can go into
this. Not only because it would be not Ada's business, but because
otherwise it would have to use some reference time. Ada does not have this,
it intentionally refused to have it when introduced Ada.Real_Time.Time. The
same arguments which were used then apply now. CPU_Time is a third time by
default absolutely independent on the other two.

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