From owner-sc22wg5@open-std.org Fri Jan 23 20:44:39 2009 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 46323CA5FED; Fri, 23 Jan 2009 20:44:39 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from ppsw-0.csi.cam.ac.uk (ppsw-0.csi.cam.ac.uk [131.111.8.130]) by www2.open-std.org (Postfix) with ESMTP id AF16BCA5FE6 for ; Fri, 23 Jan 2009 20:44:37 +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-2.csi.cam.ac.uk ([131.111.8.54]:53295) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25) with esmtpa (EXTERNAL:nmm1) id 1LQRxF-0007LU-1C (Exim 4.70) for sc22wg5@open-std.org (return-path ); Fri, 23 Jan 2009 19:44:37 +0000 Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1LQRxF-0007N1-BQ (Exim 4.67) for sc22wg5@open-std.org (return-path ); Fri, 23 Jan 2009 19:44:37 +0000 Received: from [83.67.89.123] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.1); 23 Jan 2009 19:44:37 +0000 Date: 23 Jan 2009 19:44:37 +0000 From: "N.M. Maclaren" To: WG5 Subject: Re: [ukfortran] (SC22WG5.3909) (j3.2006) [MPI3 Fortran] MPI non-blocking transfers Message-ID: In-Reply-To: <20090123190515.A5B24CA5FE6@www2.open-std.org> References: <49776DF7.1040900@cray.com> <20090121211748.130A5C178D9@www2.open-std.org> <20090121224014.6CB63C178D9@www2.open-std.org> <20090121234200.4F3BDCA3434@www2.open-std.org> <20090122000407.D5A8ECA3434@www2.open-std.org> <1232658808.15119.824.camel@math.jpl.nasa.gov> <20090123095622.CBD80CA5FED@www2.open-std.org> <20090123190515.A5B24CA5FE6@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 Jan 23 2009, Van Snyder wrote: >> >> >Fortran understands the semantics of its WAIT statement, but doesn't >> >understand the semantics of the MPI wait procedure or MPI handles. It >> >can't know that it shouldn't fiddle with the buffer if it or a subobject >> >of it doesn't appear. If its address is hiding inside of an MPI handle, >> >there's no way Fortran will know that. >> >> In theory, but not in practice. Not merely is the identifier an integer >> value (and may be the result of arbitrarily complicated extraction), the >> WAIT statement may be inside an external procedure. > >That's what the ASYNCHRONOUS attribute for arguments is supposed to >address. I am completely lost! I don't see why that attribute has anything at all to do with the WAIT statement - there isn't any reason that the buffer and the transfer identifier need be passed down through the same call chain. My point is that a compiler can't, in practice, make use of the fact that the WAIT statement completes a transfer - because it (a) can't identify the affector from the identifier and (b) can't tell which procedures might end up executing a WAIT statement and for which transfers. >> Its worst problem is that it doesn't work - or, alternatively, it needs >> Real Magic (i.e. the compiler to read the mind of the programmer). > >That statement also requres Real Magic: It requires me to read Nick's >mind ;-> In that case, I think that we have both lost each other and the thread! >> The second point is that a trivial tweak to the ASYNCHRONOUS attribute >> (or a new attribute with essentially identical properties) DOES work. >> You can prove that quite easily by drafting a design of MPI non-blocking >> I/O that uses Fortran asynchronous I/O! > >That's what the ASYNCHRONOUS attribute for arguments is supposed to >address. What's defective about it? Nothing. My objection is to 'solutions' based on procedure flags and/or the WAIT statement. >> I don't know what Resolution T7 says. Ah. Thanks. >Since MPI could in principle be implemented by asynchronous I/O >statements in external procedures, if ASYNCHRONOUS doesn't cover the >ground it needs to be repaired. The way to do that is with an >interpretation request, since it was introduced in 2003. I agree. Personally, I think that it covers the case, and am trying to find out who disagrees, and why. >Adding another attribute with "essentially identical properties" would >do nothing other than to preserve the "beloved Fortran tacked-on look" >that was lamented during the 1977 standardization. I agree there, too. 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