From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Sun Aug 11 19:26:12 2013 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id 2E59335720C; Sun, 11 Aug 2013 19:26:12 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from postout2.mail.lrz.de (postout2.mail.lrz.de [129.187.255.138]) by www.open-std.org (Postfix) with ESMTP id 9D42135693E for ; Sun, 11 Aug 2013 19:25:57 +0200 (CEST) Received: from lxmhs52.srv.lrz.de (localhost [127.0.0.1]) by postout2.mail.lrz.de (Postfix) with ESMTP id 3cCnCS4NF8zyRd for ; Sun, 11 Aug 2013 19:25:56 +0200 (CEST) X-Virus-Scanned: by amavisd-new at lrz.de in lxmhs52.srv.lrz.de Received: from postout2.mail.lrz.de ([127.0.0.1]) by lxmhs52.srv.lrz.de (lxmhs52.srv.lrz.de [127.0.0.1]) (amavisd-new, port 20024) with LMTP id LYZJXQa5Bwe8 for ; Sun, 11 Aug 2013 19:25:56 +0200 (CEST) Received: from BADWLRZ-SWHBT1.ads.mwn.de (BADWLRZ-SWHBT1.ads.mwn.de [IPv6:2001:4ca0:0:108::125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "BADWLRZ-SWHBT1", Issuer "BADWLRZ-SWHBT1" (not verified)) by postout2.mail.lrz.de (Postfix) with ESMTPS id 3cCnCS1Z1HzyRV for ; Sun, 11 Aug 2013 19:25:56 +0200 (CEST) Received: from BADWLRZ-SWMBX11.ads.mwn.de ([fe80::6de5:ff8b:1900:b1a1]) by BADWLRZ-SWHBT1.ads.mwn.de ([fe80::e42f:e9f5:bde9:f99b%16]) with mapi id 14.03.0146.000; Sun, 11 Aug 2013 19:25:56 +0200 From: "Bader, Reinhold" To: WG5 Subject: Ballot on additional coarray features (N1983) Thread-Topic: Ballot on additional coarray features (N1983) Thread-Index: Ac6Wt6tMuN6wUh6MRRCzoV39O1EYSg== Date: Sun, 11 Aug 2013 17:25:55 +0000 Message-ID: <166ED263DF83324D9A3BA67FB6772B2B5A01EC2C@BADWLRZ-SWMBX11.ads.mwn.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.187.48.193] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-sc22wg5@open-std.org Precedence: bulk Please answer the following question "Is N1983 ready for forwarding to=20 SC22 as the DTS?" in one of these ways.=20 3) No, for the following reasons: * the editor himself in 13-296 has pointed out a number of technical=20 issues that needs fixing.=20 * 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=20 opinion the right thing to do, not all possible interactions=20 with other features have been dealt with.=20 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=20 received any discussion in the last meeting.=20 On the J3 list, there was some mention of using a THIS_NODE()=20 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 in the image selector in order to be able to revert to ancestor=20 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=20 through procedure invocations during execution of the program,=20 there must be a rule (or a set of rules) that states which=20 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 =3D ... 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 =3D a[u :: 4] + ... ... end subroutine subroutine bar(a, t, u) real :: a[6:*] type(team_type) :: t, u real :: x change team (t)=20 x =3D 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,=20 and has the value 6. None of the possible answers appears entirely satisfying. Perhaps it=20 is indeed preferable to oblige the programmer to specify a remapping=20 scheme, or to simply use lists of image numbers, or (as suggested by=20 me in N1971) to prohibit coindexing of ancestor team inherited=20 coarrays altogether.=20 (A.2.4) DISTANCE optional argument In my contribution to N1971, I asked "Is it allowed to use the=20 DISTANCE argument in THIS_IMAGE if a coarray argument is also=20 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=20 to be unnecessary for FORM SUBTEAM to perform synchronization=20 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=20 received any discussion in the last meeting. I have prepared (but not yet uploaded) a J3 paper with a=20 suggested specification; it also includes an example that=20 gives an indication how this feature might be fruitfully used.=20 However, the concept presupposes that events are not reduced=20 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=20 semantics. Best wishes Reinhold