(j3.2006) (SC22WG5.5127) [ukfortran] Vote on revised draft DTS

[N.M. Maclaren]

Unfortunately, I have been slightly ill and not been able to work
effectively, so am very late.  This is not what I hope is my final
response, but includes what I propose to say except on the atomics.

I regard comments A, B, H and I as the most serious, as they are
not fixable by additional function or wording changes.



Please answer the following question "Is N1996 ready for forwarding to
SC22 as the DTS?".:

    3) No, for the following reasons.

Regards,
Nick Maclaren.




Many of the comments in N1989 have not been addressed.  These include
(with some slight modifications):

Teams
-----

Comment A
---------
    5.2 and 5.3, p9:16-*, p10:*-35.  It is still not clear whether
TEAM_TYPE objects have value or association semantics.  C502 and C503
are not enough, because of the implicit copying implied by passing
assumed-shape arrays to explicit-shape or assumed-size ones, and the
wording (e.g. R502) says 'variable'.  This is linked to the next point,
but is not the same.

However, I forgot the VALUE attribute and vector subscripts.  Fortran
2008 12.5.2.3p4 abd 16.6.1.6p4 make it very clear that a VALUE dummy
argument and dummies corresponding to vector subscripted arrays NOT the
same variable as the actual argument.  While it could be said that these
are variable definition contexts, they are NOT in the list in 16.6.5.
Is it permitted to have VALUE dummies, or vector subscript actual
arguments, and where is that stated in normative text?

Either the above loopholes must be closed, or TEAM_TYPE variables must
be stated to have value semantics (in which case forbidding assignment
is not needed).  I cannot propose edits, as I have never discovered
what mental model other people are using.


Comment B
---------
    5.3, p10:28-35.  Executing a common CHANGE TEAM statement the same
number of times is not enough, because the variable could be a dummy
argument associated with a different team on different images.  There
needs to be an explicit restriction (probably in lines 14-16) that all
variables must have been created by the same execution of the same FORM
SUBTEAM statement with the same team-id.

    TYPE(TEAM_TYPE) :: a[NUM_IMAGES()]
    DO i = 1,NUM_IMAGES()
        FORM TEAM (i,a(i))
    END DO
    CALL Fred(a(i))

    SUBROUTINE Fred (x)
    TYPE(TEAM_TYPE) :: x
    CHANGE TEAM (x)
    ...

I cannot find anywhere in the text that is forbidden, but it clearly
makes no sense.  In particular, 5.3 p10:28-35 becomes nonsense if it
is allowed.  This is simple to fix.

5.3 p10:19-21.  After "intrinsic subroutine GET TEAM (7.4.13).", add:

    "All members of the team specified by team-variable shall execute
    the CHANGE TEAM statement, and team-variable shall specify the same
    team on all images."


Comment C
---------
5.6 p11:17+.  There is nothing said about when resources may be
released, and no mechanism for the user to free them.  This is not
reasonable, and there needs to be some defined way for a programmer to
avoid memory leaks when using FORM SUBTEAM heavily.


Comment D
---------
7.4.15 p26:5-7.  I can find no guarantee that the subteam id. is
assigned in a defined order, and hope that is not the case.  The example
comments should say "Code for half of the images in the current team"
and "Code for the other half of the images in the current team".


Events
------

Comment E
---------
6.3 p15:34.  This still makes no sense, as an image control statement
cannot occur within a segment!  It should say something like "How
sequences of posts that are not ordered by other segment ordering rules
interleave with each other is processor dependent."


Comment F
---------
7.4.11 p23:25-36.  It needs to say that EVENT_QUERY may be used in
segments that are unordered with respect to EVENT POST on the same
variable.


Collectives
-----------

Comment G
---------
7.4.9 p22:16.  This makes no sense and does not address the comment
in N189, anyway.  A reduction over N images needs only N-1 pairwise
operations.  It would be far better to leave it completely open and
change:
    ", and the function shall be executed by all the images of the
    current team."
to:
    ".  It is unspecified on which images it will be called, how
    many times and on which arguments."


New Substantive Points
----------------------

EVENT POST MAX_COUNT
--------------------

Comment H
---------
Upon thinking of how to implement these facilities, I realise that the
availability of MAX_COUNT causes a serious performance loss.  Without
that, EVENT POST can be implemented by a simple fence and message
sent to the event owner.  With that, it needs to wait for a response
from the event owner, which will often cause the posting image to
block until the owning image reaches an active coarray statement.

Requiring a maximum count of 1 would have the same loss in performance,
but they would also reduce the model to one whose semantics are
understood.  As I have said before, I would regard that as a price worth
paying.

In short, I think that MAX_COUNT is a very bad idea, as it combines
the disadvantages of both general and binary semaphores.


EVENT_QUERY
-----------

Comment I
---------
There have been multiple inconclusive Email debates on exactly what is
specified, with no consensus on what should be said in normative text.
I have been convinced by them that it is not possible to produce a
consistent specification for EVENT_QUERY without introducing a
synchronisation model by the back door.  This is particularly serious
because of the EVENT_QUERY example in A.2.1 pp37-8.

One of the issues raised was whether programs like the following are
conforming:

Example event_1:
                 INTEGER :: x[*]
    On image 1                     On image 2
    POST EVENT (q[2])              CALL EVENT_QUERY (q, n)
    x[3] =  123                    IF (n >= 2) THEN
    POST EVENT (q[2])                  WAIT EVENT (q)
                                       x[3] =  456
                                   END IF

Similarly, it is unclear whether the following program is required
to complete:

Example event_2:
    On image 1                     On image 2
    POST EVENT (q[2])              DO
                                       CALL EVENT_QUERY (q, n)
                                       IF (n > 0) EXIT
                                   END DO

Also, does the same answer hold if image 1 is the event owner?

These are NOT minor points, because they have a major impact on how
EVENT_QUERY can be implemented.  In particular, if those examples are
to work, EVENT_QUERY has to be implemented using very similar
mechanisms to EVENT POST with MAX_COUNT=0.

At this late stage, I think the only feasible solution is to omit
EVENT_QUERY entirely, pending a memory model.