Re: Ada.Execution_Time

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

On 29/12/2010 16:51, in article jw9ocxiajasa.142oku2z0e6rx$.dlg@40tude.net,
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:

> On Wed, 29 Dec 2010 16:19:13 +0000, (see below) wrote:
> 
>> 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.
> 
> There exist more pragmatic considerations than the relativity theory. The
> duration you refer above is according to which clock?

I referred to time dilation to preempt your bringing it up. 8-)

> - Real time CPU counter
> - Programmable timer
> - BIOS clock
> - OS system clock
> - Ada.Real_Time.Clock
> - Ada.Calendar.Clock
> - an NTP server from the given list ...
>   ...

Quite so, but these issues, and rounding, and so on, are all subsumed under
"useful approximation".  They are implementation dependent in the best of
circumstances, and so need to be specified by the implementer.

>> It seems to me that the only grey area is the degree of approximation that
>> is acceptable for the result to be "useful".
> 
> That is the next can of worms to open. Once you decided which clock you
> take, you would have to define the sum of *which* durations according to
> this clock you are going to approximate. This would be way more difficult
> and IMO impossible. What is the "CPU" is presence of many cores? What does
> it mean for the task to be "active" keeping in mind the cases it could get
> blocked without losing the "CPU" (defined above)?

I think you are are creating unnecessary difficulties. Note that I said
nothing about CPUs, only about process states. The elapsed time between
dispatching a task/process and pre-empting or blocking it is a well defined
physical quantity. It has nothing to do with cores, and I've no idea what
"blocked without losing the CPU" means. In my dictionary that is simply
self-contradictory. But if it does mean something in some implementation,
all that is necessary is to inform of the approximation it gives rise to.

> In my humble opinion,

!-)

> ARG defined Ada.Execution_Time in the most
> *reasonable* way, in particular, allowing to deliver whatever garbage the
> underlying OS service spits.

I agree. What else could they do?
And if the implementation documents that, where is the harm?

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