From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Fri Apr 5 23:03:09 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 91100356CA2; Fri, 5 Apr 2013 23:03:05 +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 843E0356CA2 for ; Fri, 5 Apr 2013 23:03:00 +0200 (CEST) Received: from lxmhs51.srv.lrz.de (localhost [127.0.0.1]) by postout3.mail.lrz.de (Postfix) with ESMTP id CAB7020268; Fri, 5 Apr 2013 23:02:59 +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 EgBnEd5cWyvN; Fri, 5 Apr 2013 23:02:59 +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 postout3.mail.lrz.de (Postfix) with ESMTPS id 62D0D20254; Fri, 5 Apr 2013 23:02:59 +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; Fri, 5 Apr 2013 23:02:59 +0200 From: "Bader, Reinhold" To: "Bader, Reinhold" , "longb@cray.com" , sc22wg5 Subject: AW: (SC22WG5.4969) AW: (j3.2006) [ukfortran] AW: Thoughts on Reinhold's thoughts Thread-Topic: (SC22WG5.4969) AW: (j3.2006) [ukfortran] AW: Thoughts on Reinhold's thoughts Thread-Index: AQHOMkB1ykEc3z0X6Uu1CrWhO5n5oZjIHUEA Date: Fri, 5 Apr 2013 21:02:58 +0000 Message-ID: <166ED263DF83324D9A3BA67FB6772B2B59F3BEAF@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> In-Reply-To: <20130405205925.3CF0D356CCD@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 Correction of sample code below > -----Urspr=FCngliche Nachricht----- > Von: owner-sc22wg5@open-std.org [mailto:owner-sc22wg5@open-std.org] Im > Auftrag von Bader, Reinhold > Gesendet: Freitag, 5. April 2013 22:59 > An: longb@cray.com; sc22wg5 > Betreff: (SC22WG5.4969) AW: (j3.2006) [ukfortran] AW: Thoughts on Reinhol= d's > thoughts >=20 >=20 >=20 > > -----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 > > > > > > > > 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 imag= es > > > that are not part of the subteam are not involved in that collaborati= on > > > and have no obvious please to synchronise with it. > > > > 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 > > > > 1) An image in REST (actually still in parent) could define or referenc= e > > variables on an image in SOME -> havoc with the memory model. >=20 > This would apply only to coarrays inherited from the parent team, not to > team-locally generated coarrays. And for the former, the effect is not re= ally > worse than what exists now. Consider >=20 > subroutine foo(a) > real :: a(:) > ... =3D a(:) > : > end subroutine >=20 > and code invoking it thusly with 2 images: >=20 > real :: a(100)[*] >=20 > : ! initialize a > if (this_image() =3D=3D 1) then > a(:)[2] =3D ... ! must update a on image 2 here ... > else > call foo(a) > end if >=20 > Of course this is invalid code - but writing code that violates the synch= ronization > rules does not mean > that the memory model is not consistent. Some words may be needed to clar= ify > that the synchronization > rules apply with respect to the parent team for parent-team-inherited coa= rrays, > but I think this should be > no real problem. >=20 >=20 > > > > 2) The images of REST (actually still in parent) could execute SYNC AL= L > > 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. >=20 > If the images in REST do a SYNC ALL or coarray allocation prior to enteri= ng > CHANGE team, the images participating in SOME would be obliged to do so a= s > well > (and also before entering the construct), so the situation you are descri= bing > cannot > occur in valid programs. (This is in fact the case whether or not you hav= e the big > barrier in CHANGE TEAM). > For all collectively executed sync actions, I don't really see a problem.= Of course > you > need to appropriately tag these actions inside the implementation, but I = would > expect > this to work in much the same fashion as using the communicator argument = for > MPI > collectives. >=20 >=20 > 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). > > > > > > Cheers, > > Bill > > > > > > > > > > Regards, > > > Nick Maclaren. > > > > > > _______________________________________________ > > > J3 mailing list > > > J3@mailman.j3-fortran.org > > > http://mailman.j3-fortran.org/mailman/listinfo/j3 > > > > > > > -- > > 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 > >