Version 1.1 of acs/ac-00230.txt

Unformatted version of acs/ac-00230.txt version 1.1
Other versions for file acs/ac-00230.txt

!standard D.14(14.1/3)          12-02-18 AC95-00230/00
!class confirmation 12-02-18
!status received no action 12-02-18
!status received 12-02-07
!subject When is the execution time initialized?
!summary
!appendix

From: Jean-Pierre Rosen
Sent: Tuesday, February  7, 2012  12:11 AM

[Responding to review comments:]

>> D.14(14.1/3)
>>    The execution time value for the function Clock_For_Interrupts is
>>    initialized to zero {at program start-up}.
>>
>> Unless it is when the partition starts? Certainly not at the creation
>> of each task, as in D.14(13/2).
>
> "start-up" is not defined in Ada terms, and I think this was
> deliberately left a bit vague. It's not actually possible for a
> program to depend on this in any useful way (the count starts
> immediately, and some time may have been counted before the program can query the time.
>
> If we really wanted to formally define this, we'd say that it is
> initialized to zero when this package elaborates. But I'm pretty sure
> that would be overspecification.
>
> Feel free to take this to the whole group if you still disagree, I'm
> no expert on this stuff.

I'm still unconfortable when something dealing with time says it is initialized
to zero, but not when such initialization happens. Question for the York gang.

***************************************************************

From: Alan Burns
Sent: Tuesday, February  7, 2012  4:36 AM

Not sure what the issue is here, is 'program start-up' not defined?
Some vagueness would seem appropriate as the initial behaviour of a program,
especially on a multiprocessor, is not easy to define. Any implementation would
presumable document how it is measuring such times.

In terms of usage, it is unlikely any program would depend on this behaviour.
Rather a program after some initialisation would enter a 'monitoring' phase at
which point a reading of all the relevant clocks would be taken.

***************************************************************

From: Bob Duff
Sent: Tuesday, February  7, 2012  9:49 AM

> Not sure what the issue is here, is 'program start-up' not defined?

I don't know why Randy says ``"start-up" is not defined in Ada terms''.
It's crystal clear in plain English.  We really don't need to include an entire
dictionary of the English language in the RM!

But it seems wrong.  It should be initialized during elaboration of this
package, and all sorts of stuff could be happening before that.  I say:
insufficiently broken.  If we need a fix, remove this paragraph entirely, and
change (18.1/3) from "cumulative" to "total".  Everybody knows that to calculate
a total, you initialize something to zero, and add 'em up.

I wonder why this para is in Static Semantics.

Anyway, if we add "at program startup" (should be "partition startup",
really) Randy needs to schedule an hour or two at the meeting to argue about the
hyphen.  ;-)

> Some vagueness would seem appropriate as the initial behaviour of a
> program, especially on a multiprocessor, is not easy to define. Any
> implementation would presumable document how it is measuring such
> times.

I doubt any implementation would document it, and I doubt any user would care.

> In terms of usage, it is unlikely any program would depend on this
> behaviour. Rather a program after some initialisation would enter a
> 'monitoring' phase at which point a reading of all the relevant clocks
> would be taken.

Agreed.

***************************************************************

From: Randy Brukardt
Sent: Tuesday, February  7, 2012  2:37 PM

> I don't know why Randy says ``"start-up" is not defined in Ada
> terms''.
> It's crystal clear in plain English.  We really don't need to include
> an entire dictionary of the English language in the RM!

My main point is that we have formal ways of describing this, why use an
informal term? And if we're doing that simply because we don't want to really
define when this happens, then saying anything is counter-productive.

> But it seems wrong.  It should be initialized during elaboration of
> this package, and all sorts of stuff could be happening before that.
> I say: insufficiently broken.

That's what I suggested, but I thought it was overspecification.

> If we
> need a fix, remove this paragraph entirely, and change
> (18.1/3) from "cumulative" to "total".  Everybody knows that to
> calculate a total, you initialize something to zero, and add 'em up.
>
> I wonder why this para is in Static Semantics.

That's interesting. I think it is there because the CPU_Time per task is
described there (see D.14(13/2)). You could then ask why that's there...but the
whole thing is insufficiently broken. No need to change anything.

> Anyway, if we add "at program startup" (should be "partition startup",
> really)...

Which was my other point (there's no such thing as a "program"). But I wasn't
sure that's really true (perhaps it is at machine startup on some embedded
kernel -- is that good enough?) The truth is (as Alan mentions), no one will
ever really care. So the less we say the better.

***************************************************************

From: Bob Duff
Sent: Tuesday, February  7, 2012  3:03 PM

> Which was my other point (there's no such thing as a "program").

There is, but it's not what was meant here.

10.2 Program Execution

1   An Ada program consists of a set of partitions[, which can execute in
parallel with one another, possibly in a separate address space, and possibly on
a separate computer.]

>... But I
> wasn't sure that's really true (perhaps it is at machine startup on
>some  embedded kernel -- is that good enough?)

No idea -- I'd say let the market decide that point.

>...The truth is (as Alan mentions), no
> one will ever really care. So the less we say the better.

Agreed.

I don't much like "partition".  I wonder why we didn't call it "process", like
everybody else does these days.  Probably the same reason we say "access" when
everybody else says "reference" or "pointer" (or in the case of C++, both).  ;-)

***************************************************************


Questions? Ask the ACAA Technical Agent