From owner-sc22wg5@open-std.org Thu Nov 13 14:44:29 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 49393CA5FE5; Thu, 13 Nov 2008 14:44:29 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from nspiron-1.llnl.gov (nspiron-1.llnl.gov [128.115.41.81]) by www2.open-std.org (Postfix) with ESMTP id 77D01C178D9 for ; Thu, 13 Nov 2008 14:44:26 +0100 (CET) X-Attachments: None Received: from vpna-user-128-15-244-24.llnl.gov (HELO [128.15.244.24]) ([128.15.244.24]) by nspiron-1.llnl.gov with ESMTP; 13 Nov 2008 05:44:24 -0800 Message-ID: <491C2F35.30201@llnl.gov> Date: Thu, 13 Nov 2008 05:44:21 -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 Subject: Re: (j3.2006) (SC22WG5.3676) [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> <491B9DAE.4060906@llnl.gov> <20081113091819.F182BCA343B@www2.open-std.org> In-Reply-To: <20081113091819.F182BCA343B@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 Nick, This argument is not progressing too much, so better to end soon. But: > It is also totally foul to implement for ASYNCHRONOUS :-( Consider a > variable Wurzel with the ASYNCHRONOUS attribute that MAY have pending I/O > on it, and is passed as an argument to a procedure without ASYNCHRONOUS. As > I read the wording, that is permitted even if there IS pending I/O unless > that procedure actually references, defines, undefines or changes Wurzel. That is not at all what I or the paper I mentioned (08-165) said. If the variable has pending I/O on it, then the dummy should have asynchronous as well. The processor needs to do nothing different, since it is as if the variable were not asynchronous, at that point in time. The issue of "may" versus "is" I am not sure of. Without this, you make asynchronous useless, since you cannot even call an old library routine on that variable, even if there is no async I/O pending or happening. That would indeed be a BUG in the standard. And at this point in the game, we cannot change our minds to require async/volatile to be matched between dummy and actual. All combinations are allowed in F2003, and must remain so. For MPI or some such library it sure is useful to require the matching if nothing else to force programmers to put it on the actual if they are calling non-blocking I/O. But that would at this point require a new attribute indeed. Obviously, there are different mental/semantic models here of what ASYNC and VOLATILE really mean, when they are really necessary, and what guarantees/safeties the standard should provide. Perhaps the original designers had one of these models in mind, but I am not sure reading the text and as I mentioned asking J3/WG5 several times to explain it went silent. I asked what the note that 08-165 changes means and why it says what I consider obviously wrong things, and Bill at first defended it but then agreed that my suggested modification was in fact right. Anyway, we will go in circles until someone actually explains what the intention is here before we argue over edits. Best, Aleks