From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Sat Apr 6 09:46:32 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 209A23568B3; Sat, 6 Apr 2013 09:46:32 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from postout.lrz.de (postout.lrz.de [129.187.254.115]) by www.open-std.org (Postfix) with ESMTP id 5E1E83568B3 for ; Sat, 6 Apr 2013 09:46:30 +0200 (CEST) Received: from lxmhs52.srv.lrz.de (localhost [127.0.0.1]) by postout4.mail.lrz.de (Postfix) with ESMTP id 48D6920129; Sat, 6 Apr 2013 09:46:30 +0200 (CEST) X-Virus-Scanned: by amavisd-new at lrz.de in lxmhs52.srv.lrz.de Received: from postout4.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 ERh53yNmW86p; Sat, 6 Apr 2013 09:46:28 +0200 (CEST) Received: from BADWLRZ-SWHBT2.ads.mwn.de (BADWLRZ-SWHBT2.ads.mwn.de [IPv6:2001:4ca0:0:108::126]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "BADWLRZ-SWHBT2", Issuer "BADWLRZ-SWHBT2" (not verified)) by postout4.mail.lrz.de (Postfix) with ESMTPS id B210E20128; Sat, 6 Apr 2013 09:46:28 +0200 (CEST) Received: from BADWLRZ-SWMBX11.ads.mwn.de ([fe80::6de5:ff8b:1900:b1a1]) by BADWLRZ-SWHBT2.ads.mwn.de ([fe80::5951:9dc3:7b2b:14ba%13]) with mapi id 14.03.0123.003; Sat, 6 Apr 2013 09:46:28 +0200 From: "Bader, Reinhold" To: "longb@cray.com" , sc22wg5 Subject: AW: (SC22WG5.4972) (j3.2006) AW: [ukfortran] AW: Thoughts on Reinhold's thoughts Thread-Topic: (SC22WG5.4972) (j3.2006) AW: [ukfortran] AW: Thoughts on Reinhold's thoughts Thread-Index: AQHOMkZ5gqDsxN6I4UanUH8vLeayYpjIy3hg Date: Sat, 6 Apr 2013 07:46:27 +0000 Message-ID: <166ED263DF83324D9A3BA67FB6772B2B59F3BF8F@BADWLRZ-SWMBX11.ads.mwn.de> References: <20130331013557.06C46356DD4@www.open-std.org> <20130401124437.69138356A01@www.open-std.org> <20130401140345.39966356D69@www.open-std.org> <20130405202359.0F0CE356C98@www.open-std.org> <20130405205925.3CF0D356CCD@www.open-std.org> <20130405214218.B1432356D47@www.open-std.org> In-Reply-To: <20130405214218.B1432356D47@www.open-std.org> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.187.48.233] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-sc22wg5@open-std.org Precedence: bulk > -----Urspr=FCngliche Nachricht----- > Von: owner-sc22wg5@open-std.org [mailto:owner-sc22wg5@open-std.org] Im > Auftrag von Bill Long > Gesendet: Freitag, 5. April 2013 23:43 > An: sc22wg5 > Betreff: (SC22WG5.4972) (j3.2006) AW: [ukfortran] AW: Thoughts on Reinhol= d's > thoughts >=20 >=20 >=20 > On 4/5/13 3:59 PM, Bader, Reinhold wrote: > > This would apply only to coarrays inherited from the parent team, not t= o > > team-locally generated coarrays. And for the former, the effect is not = really > > worse than what exists now. Consider > > > > subroutine foo(a) > > real :: a(:) > > ... =3D a(:) > > : > > end subroutine > > > > and code invoking it thusly with 2 images: > > > > real :: a(100)[*] > > > > : ! initialize a > > if (this_image() =3D=3D 1) then > > a(:)[1] =3D ... > > else > > call foo(a) > > end if > > > > Of course this is invalid code - but writing code that violates the > synchronization rules does not mean > > that the memory model is not consistent. Some words may be needed to > clarify that the synchronization > > rules apply with respect to the parent team for parent-team-inherited > coarrays, but I think this should be > > no real problem. >=20 >=20 > I'm a bit confused here. There is no concept of an image "inheriting" > coarrays from the parent team. Coarrays belong to images, not teams. > The image is the *same* image it was before, with the same set of data. > The things that change with the new team are the image index, the > number of images, co-subscript values, and the scope of collective > operations. I assume you mean a coarray that was either statically > declared or allocated before the change to the new team, whereas a > coarray that was not allocated before but becomes allocated in the > context of the new team is not "inherited". =20 Yes, I was only using a convenient shorthand. If this needs to be formalize= d,=20 a different term may be more appropriate ... > But for the existing > coarrays, what is meant by the idea that "synchronization rules apply > with respect to the parent team"?=20 I was thinking of 8.5.2 para 3 of Fortran 2008: If definitions and referenc= es occur from an image outside the team, images inside the team need to=20 keep their hands off the object. > The image does not have access to the > images outside its team, and the SYNC operations do not involve any > images outside the team.=20 Right. Any synchronization that brings the object up-to-date by imposing segment ordering will need to occur outside the CHANGE TEAM block. My conte= ntion is that this is the *programmer's* job and should not be artificially imposed = by=20 over-constraining the team execution model. > And, once you are down in a call stack, there > would be no way to determine whether a particular coarray was in the > "inherited" camp. =20 There would be no need (and no requirement from my side) to perform=20 such determination! Again, this is rather analogous to the present case of= =20 handing a coarray to a procedure that declares the dummy to be a non-coarra= y:=20 inside the procedure, there is no way to determine that the actual is a coa= rray. (Note that your remark is relevant in a different context though, namely ho= w higher-corank coarrays or non-default lower cobound coarrays created outsid= e a team must be handled with respect to coindexing inside a team - but this is= a=20 discussion for a future thread ...) > This scheme of distinguishing coarrays and of > adding SYNC methods outside the team are a significant departure from > the basic design requirements for the current TEAM model. True - I'm trying to pull down part of T4 of N1930. >=20 > Cheers, > Bill >=20 >=20 >=20 >=20 > -- > Bill Long longb@cray.com > Fortran Technical Support & voice: 651-605-9024 > Bioinformatics Software Development fax: 651-605-9142 > Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101 >=20