From owner-sc22wg5@open-std.org Wed Sep 9 19:26:55 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 EBAC0C76BB3; Wed, 9 Sep 2009 19:26:54 +0200 (CET DST) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from ironport1.lbl.gov (ironport1.lbl.gov [128.3.41.47]) by www2.open-std.org (Postfix) with ESMTP id F25FFC178E2 for ; Wed, 9 Sep 2009 19:26:52 +0200 (CET DST) X-Ironport-SBRS: None X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwFAEOCp0qAAwWw/2dsb2JhbACQPQG+ZQmQKwKCRYFRBQ X-IronPort-AV: E=Sophos;i="4.44,359,1249282800"; d="scan'208";a="123340526" Received: from hpcrd-student51.dhcp.lbl.gov ([128.3.5.176]) by ironport1.lbl.gov with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Sep 2009 10:26:51 -0700 To: sc22wg5@open-std.org Subject: Re: (j3.2006) (SC22WG5.4074) Some minor points on the Draft Final CD Content-Disposition: inline From: Aleksandar Donev Organization: LBL Date: Wed, 9 Sep 2009 10:29:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200909091029.51037.adonev@lbl.gov> Sender: owner-sc22wg5@open-std.org Precedence: bulk Hello, Most of these have been covered already, but: > If not, there needs to be something (even just a NOTE) clarifying > what happens in these cases. 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. > 3) I think that the current wording overspecifies error termination > in paragraph 4 of 2.3.5 (Execution sequence). Specifically, > requiring one image to be able to force with others into termination > without them executing any special statement is a heavy burden on > implementors, and may not always be feasible. 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. > If people agree with me, I suggest changing: > > The synchronization step is executed by all images. > > to: > > For normal termination, the synchronization step is executed by > all images; for error termination, the synchronization of images is > processor dependent. 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. 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. Best, Aleks -- Aleksandar Donev, Ph.D. Luis W. Alvarez Postdoctoral Fellow Center for Computational Sciences and Engineering (https://ccse.lbl.gov) Lawrence Berkeley National Laboratory (http://www.lbl.gov) E-mail: adonev@lbl.gov Phone: (510) 486-5782 Fax: (510) 486-6900 Address: MS 50A-1148, LBL, 1 Cyclotron Rd., Berkeley, CA 94720 Web: http://cims.nyu.edu/~donev/