From owner-sc22wg5@open-std.org Wed Sep 9 20:32:16 2009 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www2.open-std.org Received: by www2.open-std.org (Postfix, from userid 521) id A2A35C76BB3; Wed, 9 Sep 2009 20:32:16 +0200 (CET DST) 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 E2F64C178E2 for ; Wed, 9 Sep 2009 20:32:15 +0200 (CET DST) 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]:42189) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:nmm1) id 1MlRxn-000196-N1 (Exim 4.70) for sc22wg5@open-std.org (return-path ); Wed, 09 Sep 2009 19:32:15 +0100 Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1MlRxn-0004zT-3w (Exim 4.67) for sc22wg5@open-std.org (return-path ); Wed, 09 Sep 2009 19:32:15 +0100 Received: from [83.67.89.123] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.2); 09 Sep 2009 19:32:15 +0100 Date: 09 Sep 2009 19:32:15 +0100 From: "N.M. Maclaren" To: sc22wg5@open-std.org Subject: Re: [ukfortran] (SC22WG5.4079) (j3.2006) Some minor points on the Draft Final CD Message-ID: In-Reply-To: <20090909172655.2793BC178E2@www2.open-std.org> References: <20090909172655.2793BC178E2@www2.open-std.org> X-Mailer: Prayer v1.3.2 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: owner-sc22wg5@open-std.org Precedence: bulk On Sep 9 2009, Aleksandar Donev wrote: > >You are right that 6.6 does not cover declarations, but I am not sure >what you want the Note concerning declarations to say? It has nothing >to do with the number of images---it merely sets the lower and upper >cobounds, which is independent of the number of images. Please suggest >specific wording so we know what you are asking for. Yup. I have drafted some, and will repost in due course. All it does is to say what you have said - in different words! >You are talking about ALL STOP. This is certainly a necessary >functionality. How well it is implemented, i.e., what actually happens >when it is executed, seems (almost?) entirely processor dependent to me >and I do not see how we are burdening or requiring anyone to do too >much. The problem is that paragraph 4 explicitly says that the image that initiates termination completes termination, even for ALL STOP. It might be better to drop that, instead. >Can someone explain to me how a program can detect the difference >between these and how it can tell anything about what happens after ALL >STOP is executed. All execution stops and the program cannot tell >anything about synchronization etc. Outstanding data transfers are completed, even those to data on other images (which I think is allowed). That's visible. >The synchronization is there to ensure that shared data does not >disappear until all images are done accessing it. In the case of error >termination, it does not matter----no more accessing, no more nothing, >execution ends. What is left to the OS (a whole lot of hanging >processes, a clean slate, a memory leak, or sheer peace and quiet) >seems entirely unspecified (and unspecifiable) to me. I agree, but that's not what the words say. I agree that the synchronisation is essential for ordinary STOP, but it is the ALL STOP case that concerns me. Again, I am thinking as an implementor, and as a support person faced with a case where the user claims that it should work and the vendor says that it needn't. It's not a major point, but is a problem. Regards, Nick Maclaren.