From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Sat Apr 6 13:05:23 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 6B5FB356BB3; Sat, 6 Apr 2013 13:05:12 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by www.open-std.org (Postfix) with ESMTP id 0EEBF356571 for ; Sat, 6 Apr 2013 13:05:05 +0200 (CEST) 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]:58120) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:nmm1) id 1UOQvg-0004qH-Wa (Exim 4.72) for sc22wg5@open-std.org (return-path ); Sat, 06 Apr 2013 12:05:04 +0100 Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1UOQvg-0006Q1-2P (Exim 4.72) for sc22wg5@open-std.org (return-path ); Sat, 06 Apr 2013 12:05:04 +0100 Received: from [91.125.248.181] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.5); 06 Apr 2013 12:05:04 +0100 Date: 06 Apr 2013 12:05:04 +0100 From: "N.M. Maclaren" To: sc22wg5 Subject: Re: [ukfortran] (SC22WG5.4975) AW: (j3.2006) AW: AW: Thoughts on Reinhold's thoughts Message-ID: In-Reply-To: <20130406074632.960A9356D4F@www.open-std.org> 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> <20130406074632.960A9356D4F@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 Apr 6 2013, Bader, Reinhold wrote: > >> But for the existing >> coarrays, what is meant by the idea that "synchronization rules apply >> with respect to the parent team"? > > I was thinking of 8.5.2 para 3 of Fortran 2008: If definitions and > references occur from an image outside the team, images inside the team > need to keep their hands off the object. Yes. And conversely. No ifs or buts. Well, atomics, I suppose :-( >> The image does not have access to the >> images outside its team, and the SYNC operations do not involve any >> images outside the team. > > Right. Any synchronization that brings the object up-to-date by imposing > segment ordering will need to occur outside the CHANGE TEAM block. My > contention is that this is the *programmer's* job and should not be > artificially imposed by over-constraining the team execution model. I agree. The thing I find bizarre is that we have a proven model to follow - MPI communicators and MPI_Comm_split - and I feel that any proposal should either use that as a model or explain why it isn't doing so. > (Note that your remark is relevant in a different context though, namely > how higher-corank coarrays or non-default lower cobound coarrays created > outside a team must be handled with respect to coindexing inside a team - > but this is a discussion for a future thread ...) Yes. Regards, Nick Maclaren.