From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Fri Apr 5 22:59:24 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 8E357356C92; Fri, 5 Apr 2013 22:59:24 +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 13632356C92 for ; Fri, 5 Apr 2013 22:59:20 +0200 (CEST) Received: from lxmhs51.srv.lrz.de (localhost [127.0.0.1]) by postout3.mail.lrz.de (Postfix) with ESMTP id 35ECE2024A; Fri, 5 Apr 2013 22:59:20 +0200 (CEST) X-Virus-Scanned: by amavisd-new at lrz.de in lxmhs51.srv.lrz.de Received: from postout3.mail.lrz.de ([127.0.0.1]) by lxmhs51.srv.lrz.de (lxmhs51.srv.lrz.de [127.0.0.1]) (amavisd-new, port 20024) with LMTP id hhhC12YoZUuq; Fri, 5 Apr 2013 22:59:19 +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 postout3.mail.lrz.de (Postfix) with ESMTPS id 7F26120248; Fri, 5 Apr 2013 22:59:19 +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.0123.003; Fri, 5 Apr 2013 22:59:19 +0200 From: "Bader, Reinhold" To: "longb@cray.com" , sc22wg5 Subject: AW: (SC22WG5.4967) (j3.2006) [ukfortran] AW: Thoughts on Reinhold's thoughts Thread-Topic: (SC22WG5.4967) (j3.2006) [ukfortran] AW: Thoughts on Reinhold's thoughts Thread-Index: AQHOMjuLgTV6CAKcwUSCbFbkAqsrYpjIFCKQ Date: Fri, 5 Apr 2013 20:59:18 +0000 Message-ID: <166ED263DF83324D9A3BA67FB6772B2B59F3BE99@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> In-Reply-To: <20130405202359.0F0CE356C98@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.242] 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 22:24 > An: sc22wg5 > Betreff: (SC22WG5.4967) (j3.2006) [ukfortran] AW: Thoughts on Reinhold's > thoughts >=20 >=20 >=20 > On 4/1/13 9:03 AM, N.M. Maclaren wrote: > > On Apr 1 2013, Bill Long wrote: > >> > >> Separate synchronizations of subteams is what SYNC TEAM does. If > >> that's the model that best fits a particular program, then maybe the > >> programmer should consider using SYNC TEAM instead of CHANGE TEAM. > > > > The use scenario being considered is the following: > > > > Most of the time, images run in the main team or without needing any > > synchronisation. Every so often, SOME of them need to collaborate as > > a subteam for a period, and then will rejoin the main team. The images > > that are not part of the subteam are not involved in that collaboration > > and have no obvious please to synchronise with it. >=20 > This sounds like a good use of CHANGE TEAM with two subteams, SOME and > REST. This guards against SOME starting to execute in its environment > while the images in REST are still executing as part of the parent team. > If that were not prevented, then >=20 > 1) An image in REST (actually still in parent) could define or reference > variables on an image in SOME -> havoc with the memory model. This would apply only to coarrays inherited from the parent team, not to=20 team-locally generated coarrays. And for the former, the effect is not real= ly=20 worse than what exists now. Consider subroutine foo(a) real :: a(:) ... =3D a(:) : end subroutine and code invoking it thusly with 2 images:=20 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 synchro= nization rules does not mean=20 that the memory model is not consistent. Some words may be needed to clarif= y that the synchronization rules apply with respect to the parent team for parent-team-inherited coarr= ays, but I think this should be no real problem. >=20 > 2) The images of REST (actually still in parent) could execute SYNC ALL > or allocate a coarray and hang until the images in SOME finish their > subteam work and hit the END TEAM barrier. Meanwhile, images in SOME > execute SYNC ALL or allocate coarrays without the REST images being > aware. Seems ripe for more memory model havoc. If the images in REST do a SYNC ALL or coarray allocation prior to entering CHANGE team, the images participating in SOME would be obliged to do so as = well (and also before entering the construct), so the situation you are describi= ng cannot=20 occur in valid programs. (This is in fact the case whether or not you have = the big=20 barrier in CHANGE TEAM). For all collectively executed sync actions, I don't really see a problem. O= f course you=20 need to appropriately tag these actions inside the implementation, but I wo= uld expect this to work in much the same fashion as using the communicator argument fo= r MPI collectives. Regards Reinhold >=20 > If all of the images just stay in the parent team and selectively use > SYNC TEAM for localized synchronization, you will have some confidence > about the memory model (which in that context is unchanged from F08). >=20 >=20 > Cheers, > Bill >=20 >=20 > > > > Regards, > > Nick Maclaren. > > > > _______________________________________________ > > J3 mailing list > > J3@mailman.j3-fortran.org > > http://mailman.j3-fortran.org/mailman/listinfo/j3 > > >=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