From owner-sc22wg5@open-std.org Fri Nov 7 19:16:49 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 731A0CA5FE8; Fri, 7 Nov 2008 19:16:49 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from ppsw-7.csi.cam.ac.uk (ppsw-7.csi.cam.ac.uk [131.111.8.137]) by www2.open-std.org (Postfix) with ESMTP id B0954CA343A for ; Fri, 7 Nov 2008 19:16:47 +0100 (CET) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:58369) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:nmm1) id 1KyVt1-0001sM-NW (Exim 4.70) for sc22wg5@open-std.org (return-path ); Fri, 07 Nov 2008 18:16:47 +0000 Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1KyVt1-0002t4-8w (Exim 4.67) for sc22wg5@open-std.org (return-path ); Fri, 07 Nov 2008 18:16:47 +0000 Received: from [83.67.89.123] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.1); 07 Nov 2008 18:16:47 +0000 Date: 07 Nov 2008 18:16:47 +0000 From: "N.M. Maclaren" To: sc22wg5 Subject: Re: [ukfortran] (SC22WG5.3647) (j3.2006) A comment on John Wallin's comments on Nick MacLaren's comments Message-ID: In-Reply-To: <20081107172923.2F102CA343A@www2.open-std.org> 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> <20081107172923.2F102CA343A@www2.open-std.org> X-Mailer: Prayer v1.3.1 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: owner-sc22wg5@open-std.org Precedence: bulk On Nov 7 2008, Bill Long wrote: >Aleksandar Donev wrote: >> >> 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 - ... Neither Aleksandar nor I are talking about forbidding some images to access some coarrays, nor are we talking about SYNC MEMORY overtly failing. Those are entirely separate concepts. The (simplified) issue is whether SYNC MEMORY is allowed to wait until the image that owns the data it is accessing reaches the next image control statement. No more than that. Yes, it would be possible to introduce a TIMEOUT value into SYNC MEMORY, and set STAT if it were exceeded, but that wouldn't help. All it would do is to allow a cautious programmer to diagnose the deadlock from within the program, rather than having it show up as a hung program. It wouldn't make it any easier to write portable code. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: nmm1@cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679