From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Sat Mar 30 10:41:39 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 6689A356DC5; Sat, 30 Mar 2013 10:41:39 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by www.open-std.org (Postfix) with ESMTP id 9E83D356A50 for ; Sat, 30 Mar 2013 10:41:37 +0100 (CET) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:51800) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:nmm1) id 1ULsI0-00087Q-Ql (Exim 4.72) (return-path ); Sat, 30 Mar 2013 09:41:32 +0000 Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1ULsI0-0006pB-8m (Exim 4.72) (return-path ); Sat, 30 Mar 2013 09:41:32 +0000 Received: from [87.115.144.83] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.5); 30 Mar 2013 09:41:32 +0000 Date: 30 Mar 2013 09:41:32 +0000 From: "N.M. Maclaren" To: "Bader, Reinhold" Cc: "Van.Snyder@jpl.nasa.gov" , fortran standards email list for J3 , sc22wg5 Subject: Re: [ukfortran] (SC22WG5.4944) AW: (j3.2006) Thoughts on Reinhold's thoughts Message-ID: In-Reply-To: <20130329212446.AD585356D97@www.open-std.org> References: <20130329203623.0D66F356D96@www.open-std.org> <20130329212446.AD585356D97@www.open-std.org> X-Mailer: Prayer v1.3.5 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: owner-sc22wg5@open-std.org Precedence: bulk On Mar 29 2013, Bader, Reinhold wrote: >> >> (B.1, B.4) CHANGE TEAM synchronization and ancestor-team addressing >> >> Reinhold gave an example where image 1 cannot do things asynchronously >> while the remaining images, decomposed into two teams, do something >> else, because of the synchronization requirements of CHANGE TEAM. If it >> were possible to use ancestor-team coindexing (I haven't given much >> thought to the syntax) one could decompose first into two teams, image 1 >> and the rest of them, then decompose the remaining teams: > > Unfortunately, item T2 of N1930 prohibits going outside the current team > via coindexing, and I think with good reason: It would violate > composability of the programming model. Of course, there still should be > some way of efficiently exchanging data between subteams, motivating my > desire to remove the big barrier around CHANGE TEAM (effectively saying: > If we can't pull data into a team from its inside, lets push them in from > the outside). Slightly more on this. My suggestion in my response addresses this in several ways: FORM TEAMS would be a mere collective that returns a handle but does no synchronisation CHANGE TEAMS would synchronise only the subteam, but would do so at beginning and end There would be no problem about uninvolved subteams continuing with other computation or in other subteams 'Outside' images could push data into the subteam, but it could not use it, because there is no way to synchronise. Well, actually, there is, but I am in two minds about whether it is a facility or a loophole that needs closing. If 'outside' synchronises with 'inside' using consistent atomics and SYNC MEMORY, should that be legal? While I can't think of a solid reason why not, I can think of a lot of consequences, and it won't just happen in implementations (i.e. they will have to take steps to ensure that it works). Regards, Nick.