From owner-sc22wg5@open-std.org Fri Nov 7 18:29:22 2008 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 DFF44CA5FE8; Fri, 7 Nov 2008 18:29:22 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from mail1.cray.com (mail1.cray.com [136.162.0.111]) by www2.open-std.org (Postfix) with ESMTP id CF988CA343A for ; Fri, 7 Nov 2008 18:29:20 +0100 (CET) Received: from beaver.us.cray.com (beaver.us.cray.com [172.30.74.51]) by mail1.cray.com (8.13.6/8.13.3/gw-5323) with ESMTP id mA7HTHNs010077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 7 Nov 2008 11:29:19 -0600 (CST) Received: from CFEXFE01.us.cray.com (cfexfe01.us.cray.com [172.30.74.93]) by beaver.us.cray.com (8.13.8/8.13.3/hub-5273) with ESMTP id mA7HTEnW030462 for ; Fri, 7 Nov 2008 11:29:16 -0600 Received: from mh-dhcp-172-31-16-226.us.cray.com ([172.31.16.226]) by CFEXFE01.us.cray.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Nov 2008 11:29:13 -0600 Message-ID: <49147B50.10809@cray.com> Date: Fri, 07 Nov 2008 11:30:56 -0600 From: Bill Long Reply-To: longb@cray.com Organization: Cray Inc. User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 Cc: sc22wg5 Subject: Re: (j3.2006) (SC22WG5.3645) [ukfortran] A comment on John Wallin's comments on Nick MacLaren's comments References: <20081105225653.DCEA7CA3428@www2.open-std.org> <20081106232341.ABD83CA343A@www2.open-std.org> <20081106233908.84C89C178D6@www2.open-std.org> <20081107001626.DACBFC178D6@www2.open-std.org> In-Reply-To: <20081107001626.DACBFC178D6@www2.open-std.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2008 17:29:13.0718 (UTC) FILETIME=[5A460960:01C940FE] X-Cray-VirusStatus: clean Sender: owner-sc22wg5@open-std.org Precedence: bulk Aleksandar Donev wrote: > On Thursday 06 November 2008 15:39, N.M. Maclaren wrote: > > >>> Deadlocks introduced by the implementation should be reported as bugs to >>> the vendor. >>> >> Unless the standard makes it clear whether the programmer or implementor >> is at fault, that is merely a waste of time. >> > I have been discussing these things with Nick in private for some time now, so > let me say a few words to WG5 (since I won't be in Tokyo---I think arguing > over e-mail is somewhat inefficient and wasteful). > > I agree with Nick that we should make a decision concerning "progress", and > somehow anoint in the standard, even if we cannot say anything in > standardese. The first sentence of Note 8.31 is "The model upon which the interpretation of a program is based is that there is a permanent memory location for each coarray and the all images can access it." I don't see any ambiguity here. It does not say that only some images can access a coarray, or that the access is available only some of the time. Perhaps we should change "access" to "reference or define" (an early UK point) to make use of well defined terms here. But the key words near the end of the sentence, ALL and CAN have unambiguous meanings. The other issue related to progress is whether there is an expectation that a SYNC MEMORY statement actually completes execution. Since SYNC MEMORY is implicitly part of the other image control statements, assuring that one works solves the global problem. We do already allow, via the stat specifier, a way to deal with cases where the statement in fact does fail - for example if there is a bad memory chip storing affected data, the network is physically severed, or there is a power failure on an affected image. In Note 8.40 we explicitly say that the errors that cause a non-zero stat return are "processor dependent". However, there is an implicit assumption that on a normally functioning system, SYNC MEMORY would always complete with a zero status. If we need to say that, I suppose it is OK. Although there are a lot of other statements (READ and WRITE, for example) where we implicitly assume that they do what the standard says they do without explicitly saying so. Probably because there is a blanket statement on page 2 that requires a standard-conforming processor to execute statements in the way the standard specifies. Cheers, Bill -- Bill Long longb@cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120