From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Sat Mar 30 12:41:21 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 97F05356DD7; Sat, 30 Mar 2013 12:41:21 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by www.open-std.org (Postfix) with ESMTP id 52BDD3569F1 for ; Sat, 30 Mar 2013 12:41:18 +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]:49253) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:nmm1) id 1ULu9r-0002L4-r9 (Exim 4.72) (return-path ); Sat, 30 Mar 2013 11:41:15 +0000 Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1ULu9r-0007zj-Ew (Exim 4.72) (return-path ); Sat, 30 Mar 2013 11:41:15 +0000 Received: from [87.115.144.83] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.5); 30 Mar 2013 11:41:15 +0000 Date: 30 Mar 2013 11:41:15 +0000 From: "N.M. Maclaren" To: "Bader, Reinhold" Cc: "Van.Snyder@jpl.nasa.gov" , fortran standards email list for J3 , sc22wg5 Subject: Re: AW: AW: (SC22WG5.4945) [ukfortran] AW: (j3.2006) Thoughts on Reinhold's thoughts Message-ID: In-Reply-To: <166ED263DF83324D9A3BA67FB6772B2B59F2B546@BADWLRZ-SWMBX11.ads.mwn.de> References: <20130329203623.0D66F356D96@www.open-std.org> <20130329212446.AD585356D97@www.open-std.org> <20130329231248.0A33D356DA7@www.open-std.org> <166ED263DF83324D9A3BA67FB6772B2B59F2B4D0@BADWLRZ-SWMBX11.ads.mwn.de> <166ED263DF83324D9A3BA67FB6772B2B59F2B546@BADWLRZ-SWMBX11.ads.mwn.de> 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 30 2013, Bader, Reinhold wrote: > > Note that since your suggestion also involves relaxation of the CHANGE > TEAM synchronization semantics, you're under obligation of providing > proof of correctness as well ... Accepted :-) That suggestion (and it's most definitely inchoate) was because of all of the fundamental objections I had to the facility proposed in the draft TS. That definitely won't work. I can see three approaches, in various levels of severity: 1) To forbid ALL communication from inside or outside a team to the other, even for coarrays that are used only in one place 2) To forbid any synchronisation between inside and outside, though to permit the outside to access inside coarrays not used inside 3) To allow limited synchronisation between inside and outside, whether by using atomics and SYNC MEMORY or otherwise (1) is easy to validate, (2) doesn't introduce any consistency problems though it might introduce deadlock, and (3) is the one I get twitchy about. Regards, Nick Maclaren.