Version 1.4 of ai12s/ai12-0082-1.txt

Unformatted version of ai12s/ai12-0082-1.txt version 1.4
Other versions for file ai12s/ai12-0082-1.txt

!standard D.16.1(16/3)          14-05-08 AI05-0082-1/03
!standard D.16.1(22/3)
!standard D.16.1(25/3)
!standard D.16.1(27/3)
!standard D.16.1(29/3)
!class binding interpretation 13-10-21
!status Corrigendum 2014 13-12-07
!status WG9 Approved 14-06-27
!status ARG Approved 9-0-2 13-11-15
!status work item 13-10-21
!status received 13-06-16
!priority Low
!difficulty Easy
!qualifier Omission
!subject Definition of "dispatching domain"
!summary
"Dispatching_Domain" is replaced by "dispatching domain" in most uses, and "dispatching domain" is defined appropriately.
!question
There are many occurrences where Dispatching_Domain (the name of a type) in D.16.1 should be replaced by "dispatching domain" (the semantic concept behind the type) or some similar change. For instance, one does not assign to Dispatching_Domain, as it is a type. Fix this? (Yes.)
!recommendation
(See Summary.)
!wording
Modify D.16.1(16/3):
{A dispatching domain}[The type Dispatching_Domain] represents a {set}[series] of processors on which a task may execute. Each processor is contained within exactly one {dispatching domain}[Dispatching_Domain]. {An object of type Dispatching_Domain identifies a dispatching domain.} System_Dispatching_Domain {identifies a domain that} contains the processor or processors on which the environment task executes. At program start-up all processors are contained within {this domain}[System_Dispatching_Domain].
In D.16.1(22/3), replace "Dispatching_Domain" with "the dispatching domain", and replace "range" with "set". In D.16.1(25/3), D.16.1(27/3) [two places], and D.16.1(29/3), replace "Dispatching_Domain" with "dispatching domain".
!discussion
Unfortunately, just using "dispatching domain" brings up the question of what is a "dispatching domain" (as opposed to a "Dispatching_Domain"). The standard uses the term but never defines it.
Thus, the first thing we have to do is define the term "dispatching domain". The easiest solution is to define it to be "an object of type Dispatching_Domain". However, since a CPU can belong to only one dispatching domain, and Get_Dispatching_Domain returns what is effectively a reference to an existing domain, this doesn't work.
Thus we have to turn the definition around and make "an object of type Dispatching_Domain identify a dispatching domain", with "dispatching domain" defined similarly to "Type Dispatching_Domain" in the existing wording.
Some changes from "Dispatching_Domain" to "dispatching domain" were made in AI12-0033-1 (in paragraphs modified by that AI).
We change "series" (D.16.1(16/3)) and "range" (D.16.1(22/3)) to "set" as a dispatching domain might be a discontiguous set of CPU values and the words "series" and "range" seem to imply a continguous range of CPU values.
!corrigendum D.16.1(16/3)
Replace the paragraph:
The type Dispatching_Domain represents a series of processors on which a task may execute. Each processor is contained within exactly one Dispatching_Domain. System_Dispatching_Domain contains the processor or processors on which the environment task executes. At program start-up all processors are contained within System_Dispatching_Domain.
by:
A dispatching domain represents a set of processors on which a task may execute. Each processor is contained within exactly one dispatching domain. An object of type Dispatching_Domain identifies a dispatching domain. System_Dispatching_Domain identifies a domain that contains the processor or processors on which the environment task executes. At program start-up all processors are contained within this domain.
!corrigendum D.16.1(22/3)
Replace the paragraph:
If both Dispatching_Domain and CPU are specified for a task, and the CPU value is not contained within the range of processors for the domain (and is not Not_A_Specific_CPU), the activation of the task is defined to have failed, and it becomes a completed task (see 9.2).
by:
If both the dispatching domain and CPU are specified for a task, and the CPU value is not contained within the set of processors for the domain (and is not Not_A_Specific_CPU), the activation of the task is defined to have failed, and it becomes a completed task (see 9.2).
!corrigendum D.16.1(25/3)
Replace the paragraph:
The function Get_Dispatching_Domain returns the Dispatching_Domain on which the task is assigned.
by:
The function Get_Dispatching_Domain returns the dispatching domain on which the task is assigned.
!corrigendum D.16.1(27/3)
Replace the paragraph:
A call of procedure Set_CPU assigns task T to the CPU. Task T can now execute only on CPU, unless CPU designates Not_A_Specific_CPU, in which case it can execute on any processor within its Dispatching_Domain. The exception Dispatching_Domain_Error is propagated if CPU is not one of the processors of the Dispatching_Domain on which T is assigned (and is not Not_A_Specific_CPU). A call of Set_CPU is a task dispatching point for task T unless T is inside of a protected action, in which case the effect on task T is delayed until its next task dispatching point. If T is the Current_Task the effect is immediate if T is not inside a protected action, otherwise the effect is as soon as practical.
by:
A call of procedure Set_CPU assigns task T to the CPU. Task T can now execute only on CPU, unless CPU designates Not_A_Specific_CPU, in which case it can execute on any processor within its dispatching domain. The exception Dispatching_Domain_Error is propagated if CPU is not one of the processors of the dispatching domain on which T is assigned (and is not Not_A_Specific_CPU). A call of Set_CPU is a task dispatching point for task T unless T is inside of a protected action, in which case the effect on task T is delayed until its next task dispatching point. If T is the Current_Task the effect is immediate if T is not inside a protected action, otherwise the effect is as soon as practical.
!corrigendum D.16.1(29/3)
Replace the paragraph:
A call of Delay_Until_And_Set_CPU delays the calling task for the designated time and then assigns the task to the specified processor when the delay expires. The exception Dispatching_Domain_Error is propagated if P is not one of the processors of the calling task's Dispatching_Domain (and is not Not_A_Specific_CPU).
by:
A call of Delay_Until_And_Set_CPU delays the calling task for the designated time and then assigns the task to the specified processor when the delay expires. The exception Dispatching_Domain_Error is propagated if P is not one of the processors of the calling task's dispatching domain (and is not Not_A_Specific_CPU).
!ASIS
No changes needed.
!ACATS test
No test needed.
!appendix

!standard D.16.1
!from Erhard Ploedereder
!editorial

!question

There are many occurrences where Dispatching_Domain (the name of a type) in D.16.1
should be replaced by "dispatching domain" (the semantic concept behind the type).
While some can be argued about, there are some that are plain wrong: E.g., One does
not assign to Dispatching_Domain, ever! Assignment to types?? Of course not.

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

From: Randy Brukardt
Sent: Monday, October 21, 2013  7:07 PM

The problem with this, of course, is that the term "dispatching domain" is never
defined anywhere. It *is* used in some existing wording, but that just compounds
the problem.

I started therefore by adding a definition of the term in D.16.1(16/3):

The type Dispatching_Domain represents a series of processors on which a task may
execute{; an object of type Dispatching_Domain is called a *dispatching domain*}.
Each processor is contained within exactly {one object of type} Dispatching_Domain.
System_Dispatching_Domain contains the processor or processors on which the
environment task executes. At program start-up all processors are contained within
System_Dispatching_Domain.

This matches my understanding of the intent. In addition, since type
Dispatching_Domain is limited, an object is the same as a value.

However, with this definition in place, I can't figure out what Get_Dispatching_Domain
is supposed to do. If it makes a copy of the object (somehow), then the "exactly one"
wording of D.16.1(16/3) is clearly violated.

    declare
        My_Domain : constant Get_Dispatching_Domain (Ada.Task_Identification.Current_Task);
           -- There are now two dispatching domain objects containing "Current_Task".
    begin
        ...

If doesn't make a copy, how does that work?

The alternative would be to define "dispatching domain" separate from "an
object of type Dispatching_Domain". That would make D.16.1(16/3) start something
like:

{A *dispatching domain*}[The type Dispatching_Domaian] represents a series of
processors on which a task may execute. Each processor is contained within
exactly {dispatching domain}[Dispatching_Domain]. ??? System_Dispatching_Domain
contains the processor or processors on which the environment task executes. At
program start-up all processors are contained within System_Dispatching_Domain.

But at the point "???" we then have to add something to describe the meaning
of type Dispatching_Domain and the correspondence between an object of type
Dispatching_Domain and a *dispatching domain*. And it seems that that would
have to be very loose in order for Get_Dispatching_Domain to make sense. And if
we do that, little of the existing wording makes any sense (most of it uses
"Dispatching_Domain" meaning an object of that type). We can make it make sense
by rewriting it to use "dispatching domain" exclusively; but then there is no
connection between the parameters and their meanings.

In any case, this seems to be a heck of a lot more significant change that a
"presentation AI" as I was directed back to make in June. We have to define
a term, and the definition is not obvious to me. And using that term rather 
than "an object of type Dispatching_Domain" substantially changes the semantics
(even if it doesn't change the intent). Unless I've missed something, we'll
have to withdraw AI12-0033-1 from WG 9 consideration (since I made some of
the "presentation" changes in that AI, and it's too late to edit it before the
WG 9 meeting), and then we might as well add this problem to that AI rather
than creating a new one.

Thoughts?

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

From: Tucker Taft
Sent: Monday, October 21, 2013  7:49 PM

> However, with this definition in place, I can't figure out what 
> Get_Dispatching_Domain is supposed to do. If it makes a copy of the 
> object (somehow), then the "exactly one" wording of D.16.1(16/3) is 
> clearly violated.
>
>      declare
>          My_Domain : constant Get_Dispatching_Domain 
> (Ada.Task_Identification.Current_Task);

This isn't legal Ada syntax.  You need a type name and an assignment in
their somewhere!

>             -- There are now two dispatching domain objects containing 
> "Current_Task".
>      begin
>          ...
>
> If doesn't make a copy, how does that work? ...

Since the partial view of Dispatching_Domain is limited, that does make it
a bit harder to answer this question.  To implement Get_Dispatching_Domain,
clearly the full type has to be non-limited.  So apparently a value of type
Dispatching_Domain "identifies" a dispatching domain, rather than *is* one,
similar to the way task types work.

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

From: Randy Brukardt
Sent: Monday, October 21, 2013  7:49 PM

...
> > However, with this definition in place, I can't figure out what 
> > Get_Dispatching_Domain is supposed to do. If it makes a copy of the 
> > object (somehow), then the "exactly one" wording of D.16.1(16/3) is 
> > clearly violated.
> >
> >      declare
> >          My_Domain : constant Get_Dispatching_Domain 
> > (Ada.Task_Identification.Current_Task);
> 
> This isn't legal Ada syntax.  You need a type name and an assignment 
> in their somewhere!

Arrrgghh! I think you know what I meant.

> >             -- There are now two dispatching domain objects containing
> >             -- "Current_Task".
> >      begin
> >          ...
> >
> > If doesn't make a copy, how does that work? ...
> 
> Since the partial view of Dispatching_Domain is limited, that does 
> make it a bit harder to answer this question.  To implement 
> Get_Dispatching_Domain, clearly the full type has to be non-limited.  
> So apparently a value of type Dispatching_Domain "identifies" a 
> dispatching domain, rather than *is* one, similar to the way task 
> types work.

How do we explain that in wording? In particular, what goes into the ???
in my suggested replacement for D.16.1(16/3):

{A *dispatching domain*}[The type Dispatching_Domain] represents a series of
processors on which a task may execute. Each processor is contained within
exactly one {dispatching domain}[Dispatching_Domain]. ???
System_Dispatching_Domain contains the processor or processors on which the
environment task executes. At program start-up all processors are contained
within System_Dispatching_Domain.

I suppose we could use the wording you gave above:

"An object of type Dispatching_Domain identifies a dispatching domain."

Is this OK for the RM? If so, I can look at the rest of the wording to see if
it makes sense (or not) with these definitions. (In any case, this is not a
presentation AI!)

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

From: Tucker Taft
Sent: Monday, October 21, 2013  8:27 PM

> I suppose we could use the wording you gave above:
>
> "An object of type Dispatching_Domain identifies a dispatching domain."
>
> Is this OK for the RM?

Yes, it seems fine.  You could say "value" instead of "object," but either is
probably fine, since it is of a limited type (at least externally).

Note that the "Standard_Input" function is similar.  It says it "returns the
standard input file" and doesn't bother to mention that saving this value does
*not* create a distinct file, but just refers to the same file.  So we could
just wave our hands and be no worse than Standard_Input, but I think most of
us would agree that we don't particularly want to use Text_IO as a model if we
don't have to... ;-)

> ... If so, I can look at the rest of the wording to see if it makes 
> sense (or not) with these definitions. (In any case, this is not a 
> presentation AI!)

I think it is a bit of an angels-on-the-pin issue as far as most people are
concerned, but it would be nice to eliminate some of the logical
inconsistencies.

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

From: Randy Brukardt
Sent: Monday, October 21, 2013  9:23 PM

...
> > I suppose we could use the wording you gave above:
> >
> > "An object of type Dispatching_Domain identifies a dispatching domain."
> >
> > Is this OK for the RM?
> 
> Yes, it seems fine.  You could say "value" instead of "object," but 
> either is probably fine, since it is of a limited type (at least 
> externally).

Right.

...
> > ... If so, I can look at the rest of the wording to see if it makes 
> > sense (or not) with these definitions. (In any case, this is not a 
> > presentation AI!)
> 
> I think it is a bit of an angels-on-the-pin issue as far as most 
> people are concerned, but it would be nice to eliminate some of the 
> logical inconsistencies.

I'm only doing this because Erhard insisted that we correct this wording. I
would have been happy to ignore it as insufficiently broken...

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

Questions? Ask the ACAA Technical Agent