From owner-sc22wg5@open-std.org Thu Jun 11 04:08:08 2009 Return-Path: X-Original-To: sc22wg5-dom7 Delivered-To: sc22wg5-dom7@www2.open-std.org Received: by www2.open-std.org (Postfix, from userid 521) id D8390C76BB7; Thu, 11 Jun 2009 04:08:08 +0200 (CET DST) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 1378 seconds by postgrey-1.18 at www2.open-std.org; Thu, 11 Jun 2009 04:08:06 CET DST Received: from ns.nag-j.co.jp (218-42-159-107.cust.bit-drive.ne.jp [218.42.159.107]) by www2.open-std.org (Postfix) with ESMTP id 48654C4596B for ; Thu, 11 Jun 2009 04:07:42 +0200 (CET DST) Received: from 218-42-159-108.cust.bit-drive.ne.jp ([218.42.159.108] helo=[127.0.0.1]) by ns.nag-j.co.jp with esmtp (Exim 4.50) id 1MEZIz-0007O2-Ti; Thu, 11 Jun 2009 10:42:13 +0900 Message-ID: <4A306193.5050708@nag-j.co.jp> Date: Thu, 11 Jun 2009 10:44:51 +0900 From: Malcolm Cohen User-Agent: Thunderbird 3.0a1pre (Windows/2008022014) MIME-Version: 1.0 To: fortran standards email list for J3 , WG5 Subject: Re: (j3.2006) (SC22WG5.3998) [ukfortran] New summary of coarrays References: <20090609092023.32AF5C178DC@www2.open-std.org> <20090609093907.2863CC178DC@www2.open-std.org> <4A2E63B2.6020400@cray.com> In-Reply-To: <4A2E63B2.6020400@cray.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-sc22wg5@open-std.org Precedence: bulk Hi Bill and Craig, Craig Dedo, and then Bill Long, wrote to J3 replying to a WG5 message... Once again I reiterate my "watch what you are replying to" : J3 list readers please use "Reply All" or manually reinsert the WG5 list when replying to a WG5 message. I am copying this to WG5 just so I can stick my oar in on the substance. Craig Dedo wrote replying to Nick (I think): > Everyone: > I believe that a better wording for the last sentence would be: > > The exact details are left processor dependent. Therefore, > programmers should read their processor documentation before using atomic > subroutines. > > I believe that "processor documentation" is the recommended term. > Also, breaking it up into two sentences makes it read better. > And Bill Long replied: > Both versions presume something that seems very unlikely - that vendors > discuss such implementation and performance details in their > documentation. I think the whole addition should be dropped. At best it > is confusing to an ordinary user; at worst is encourages vendors to not > bother doing a good job. > No, as I understand it existing hardware and physical constraints encourages some vendors not to have global consistency; *and* we allow them not to have global consistency. As for "confusing to an ordinary user", not nearly as confusing as getting wildly different answers or program hangs/crashes from the same data on the same machine on a Thursday. Cheers, -- ..........................Malcolm Cohen, Nihon NAG, Tokyo.