From owner-sc22wg5@open-std.org Thu Nov 13 04:23:32 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 37200CA343B; Thu, 13 Nov 2008 04:23:32 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from smtp.llnl.gov (nspiron-3.llnl.gov [128.115.41.83]) by www2.open-std.org (Postfix) with ESMTP id 25AF0C178D9 for ; Thu, 13 Nov 2008 04:23:30 +0100 (CET) X-Attachments: None Received: from vpna-user-128-15-244-18.llnl.gov (HELO [128.15.244.18]) ([128.15.244.18]) by smtp.llnl.gov with ESMTP; 12 Nov 2008 19:23:27 -0800 Message-ID: <491B9DAE.4060906@llnl.gov> Date: Wed, 12 Nov 2008 19:23:26 -0800 From: Aleksandar Donev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.8) Gecko/20071009 SeaMonkey/1.1.5 MIME-Version: 1.0 To: WG5 Cc: "N.M. Maclaren" Subject: Re: (j3.2006) (SC22WG5.3666) [ukfortran] N1755: Request for new features from MPI Forum References: <49137AD3.1070402@lrz.de> <20081111214622.271B9C178D6@www2.open-std.org> <20081111223447.BD40BC178D9@www2.open-std.org> <20081111224927.8201CC178D9@www2.open-std.org> <20081112085745.2228AC178D9@www2.open-std.org> In-Reply-To: <20081112085745.2228AC178D9@www2.open-std.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-sc22wg5@open-std.org Precedence: bulk Hi, I am confused as to whether this should go to WG5 or J3. I thought we were not to have long technical arguments on WG5? > Eh? What about NOTE 12.22? Do you get WG5 e-mails? Did you get my response to your message and take a look at paper 08-165 and also 08-165r1.txt from meeting 184? That paper of mine changed that Note! I don't have the exact new text (the paper gives diff edits), but the intention is: "That is, the aversion to copy-in/out is only necessary, and therefore should only apply, if there is any chance that the volatility and/or asynchronicity is active either before or after the procedure call; there is no problem if it is limited to only being within the called procedure itself." The relevant parts of 08-165 are appended below, for your consideration (please read that before continuing). >> 2. "C559 An entity with the VOLATILE attribute shall be a variable that >> is not an INTENT (IN) dummy argument." Please explain this one to me. > Bill has explained this one. Except that, in my response, and Van's, we specifically disagreed with the "explanation" and essentially called it an obfuscation. Did you read those? Further comments in response to second e-mail follow. Best, Aleks ==== What the Note should really say, according to 08-185: "Just because the dummy argument has the ASYNCHRONOUS attribute does not imply that the corresponding actual argument necessarily has the attribute, and vice versa. In particular, if during the execution of the procedure the actual argument is not a pending I/O storage sequence affector (9.6.2.5) the dummy argument is not required to have the ASYNCHRONOUS attribute. Similarly, if all asynchronous I/O involving the dummy argument completes before the procedure completes execution, the actual argument is not required to have the ASYNCHRONOUS attribute. If, however, the values of an actual argument can change due to an asynchronous I/O operation while the procedure is in execution, the dummy argument should also have the corresponding (ASYNCHRONOUS or VOLATILE) attribute. Similarly, if an asynchronous I/O operation involving the dummy argument begins during the execution of the procedure but does not complete before the procedure completes execution, the actual is required to have the ASYNCHRONOUS attribute. The constraints on actual arguments with the ASYNCHRONOUS attribute that correspond to a dummy argument with the ASYNCHRONOUS attribute are designed to avoid forcing a processor to use the so-called copy in/copy-out argument passing mechanism. If copy in/copy-out occurs then any changes to the values of the actual due to asynchronous I/O will be lost when the called procedure returns and the copy-out overwrites the actual argument, and any changes of the values of the actual argument will not be visible during the execution of the procedure. Similarly, if copy in/out occurs and an asynchronous I/O operation begins but does not complete during the execution of the procedure, the operation will fail when the copy is deallocated upon return from the procedure. Identical considerations apply to the VOLATILE attribute, with the only difference that the values of the dummy or actual argument change by means outside of the program, rather than asynchronous I/O."