From owner-sc22wg5@open-std.org Fri Jan 23 20:05:15 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 8756CCA5FED; Fri, 23 Jan 2009 20:05:15 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from mail.jpl.nasa.gov (sentrion1.jpl.nasa.gov [128.149.139.105]) by www2.open-std.org (Postfix) with ESMTP id 9A10DCA5FE6 for ; Fri, 23 Jan 2009 20:05:13 +0100 (CET) Received: from mprox2.jpl.nasa.gov (mprox2.jpl.nasa.gov [137.78.160.141]) by mail.jpl.nasa.gov (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n0NJ59S0013379 for ; Fri, 23 Jan 2009 19:05:10 GMT Received: from [137.79.7.57] (math.jpl.nasa.gov [137.79.7.57]) (authenticated bits=0) by mprox2.jpl.nasa.gov (Switch-3.2.6/Switch-3.2.6) with ESMTP id n0NJ58DJ027192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 23 Jan 2009 11:05:08 -0800 Subject: Re: (j3.2006) (SC22WG5.3907) [ukfortran] [MPI3 Fortran] MPI non-blocking transfers From: Van Snyder Reply-To: Van.Snyder@jpl.nasa.gov To: WG5 In-Reply-To: <20090123095622.CBD80CA5FED@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> Content-Type: text/plain Organization: Yes Date: Fri, 23 Jan 2009 11:05:07 -0800 Message-Id: <1232737508.15119.885.camel@math.jpl.nasa.gov> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-8.el5_2.3) Content-Transfer-Encoding: 7bit X-Source-IP: math.jpl.nasa.gov [137.79.7.57] X-Source-Sender: Van.Snyder@jpl.nasa.gov X-AUTH: Authorized Sender: owner-sc22wg5@open-std.org Precedence: bulk On Fri, 2009-01-23 at 01:56 -0800, N.M. Maclaren wrote: > On Jan 22 2009, Van Snyder wrote: > > > >> That is why a buffer and all 'active' associated entities must be > >> marked as ASYNCHRONOUS or equivalent for the whole of that period. > > > >Yes, that's what the ASYNCHRONOUS attribute is for, but if a variable > >with the ASYNCHRONOUS attribute doesn't appear, the compiler can't know > >not to do something in a context where it might nonetheless be affected > >in the ways you describe. > > That is why all associated entities must have the ASYNCHRONOUS attribute. > If you mean that the compiler has to do something special in any place > that no such entity appears, that is not the case. > > >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. > >> >One simple step toward solving the problem is to write an extra > >> >interface layer that includes the argument, which then calls the real > >> >MPI wait routine, not passing that argument. Then declaring the buffer > >> >and the dummy argument of the wait routine interface layer to be > >> >ASYNCHRONOUS ought to work, according to the rules we already have in > >> >place for Fortran asynchronous I/O. > >> > >> That is the solution which I thought about some time ago, and came to the > >> conclusion "don't start from here". > > > >That's too vague to draw any conclusions. So far, in all my > >consideration of this matter, it seems to be the only solution that > >works, without enormous amounts of magic that would probably violate > >Resolution T7. > > 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 ;-> > 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? > I don't know what Resolution T7 says. >From N1758: T7. Technical Content of Fortran 2008 CD That WG5 establishes that the technical content of the draft revised standard for Fortran which is scheduled to be submitted to SC22 for FCD ballot in 2009 shall be that in WG5-N1723 (also known as SC22 N4319 and 08-007r2) as modified by the edits specified in WG5-N1760. The primary development body is encouraged to make editorial corrections and clarifications and to resolve inconsistencies, but the technical content should not be changed unless a serious flaw is found. 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. 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. > > > 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 > > _______________________________________________ > J3 mailing list > J3@j3-fortran.org > http://j3-fortran.org/mailman/listinfo/j3