(j3.2006) (SC22WG5.5071) Ballot on additional coarray features (N1983)

[Bader, Reinhold]

Please answer the following question "Is N1983 ready for forwarding to 
SC22 as the DTS?" in one of these ways. 

3) No, for the following reasons:

* the editor himself in 13-296 has pointed out a number of technical 
  issues that needs fixing. 
* there are still some items from the first comment round N1971 that
  have not yet been discussed; in particular the issue of how the
  atomic functions behave has not yet been satisfactorily resolved.
* while removing the "big barrier" from CHANGE TEAM was in my 
  opinion the right thing to do, not all possible interactions 
  with other features have been dealt with. 

Here some more detailed comments on N1983:

(A) Teams:
~~~~~~~~~~

(A.1) Missing support for computational domains

This is item (B.2) from my comments in N1971 which has not 
received any discussion in the last meeting. 
On the J3 list, there was some mention of using a THIS_NODE() 
intrinsic to achieve the desired effect. However, I believe that
this is not quite sufficient for what is in general required, and
therefore have submitted 13-300 with a suggested specification
for a DOMAIN argument to the FORM SUBTEAM statement.

(A.2) Issues with team coindexing

N1983 has introduced the concept of specifying a <team-variable>
in the image selector in order to be able to revert to ancestor 
team coindexing. There are some open questions here:

(A.2.1) Is it intended that cosubscripts can be specified that
address an image outside the presently executing team? If not
(which is the answer I favor, in order to keep the scheme as
simple as possible, while retaining the possibility of future
extension), a restriction that states this must be added.

(A.2.2) A restriction is missing that the coarray on which the
new addressing scheme is used must have been established by
the referenced team or an ancestor of it.

(A.2.3) Because coarrays can change their corank and cobounds 
through procedure invocations during execution of the program, 
there must be a rule (or a set of rules) that states which 
corank and cobounds the team coindexing scheme refers to.

Consider the following example:

real, allocatable :: a[:]
type(team_type) :: t, u

allocate(a[4:*])

form subteam(..., u) ! original team
id = ...
form subteam(id, t)

change team(t)
  call foo(a, u)
end team

call bar(a, t, u)

with foo and bar as follows:

subroutine foo(a, u)
  real :: a[6:*]
  type(team_type) :: u
  real :: x
  x = a[u :: 4] + ...
  ...
end subroutine
subroutine bar(a, t, u)
  real :: a[6:*]
  type(team_type) :: t, u
  real :: x
  change team (t) 
    x = a[u :: 4] + ...
  end team
  ...
end subroutine

The question is whether the coindexed access in bar is to image
1 of the original team (because that is the way the ALLOCATE statement
established the coarray), or whether it is invalid because the last
known lower cobound when executing with the specified team is relevant, 
and has the value 6.
None of the possible answers appears entirely satisfying. Perhaps it 
is indeed preferable to oblige the programmer to specify a remapping 
scheme, or to simply use lists of image numbers, or (as suggested by 
me in N1971) to prohibit coindexing of ancestor team inherited 
coarrays altogether. 

(A.2.4) DISTANCE optional argument

In my contribution to N1971, I asked "Is it allowed to use the 
DISTANCE argument in THIS_IMAGE if a coarray argument is also 
specified?". This question was never answered; if the answer was
intended to be "yes", a similar issue as for (A.2.3) above must
be addressed, and IMAGE_INDEX should be analogously extended.

(A.3) Form subteam properties

Given the synchronization properties of CHANGE TEAM, it appears 
to be unnecessary for FORM SUBTEAM to perform synchronization 
of all images, or for it to be an image control statement.

Furthermore, allowing a team variable to have the POINTER attribute
was considered useful. I agree with this, but would suggest to prohibit
a POINTER team variable in an execution of FORM SUBTEAM (it would
however be allowed in execution of a CHANGE TEAM).


(B) Events:
~~~~~~~~~~~

(B.1) Split phase barrier

This is item (C.2) from my comments in N1971 which has not 
received any discussion in the last meeting.
I have prepared (but not yet uploaded) a J3 paper with a 
suggested specification; it also includes an example that 
gives an indication how this feature might be fruitfully used. 
However, the concept presupposes that events are not reduced 
to only binary semaphores as suggested by Nick MacLaren.


(C) Atomic functions:
~~~~~~~~~~~~~~~~~~~~~

I agree with Malcolm and Nick that specification of a memory
model for the atomic functions is desirable. Depending on the
outcome, it should then also be possible to decide whether or
not it is necessary to make further changes to the event 
semantics.


Best wishes
Reinhold