From owner-sc22wg5@open-std.org Fri Jan 23 10:56:22 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 797BCCA5FFA; Fri, 23 Jan 2009 10:56:22 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from ppsw-6.csi.cam.ac.uk (ppsw-6.csi.cam.ac.uk [131.111.8.136]) by www2.open-std.org (Postfix) with ESMTP id 947C7CA5FED for ; Fri, 23 Jan 2009 10:56:20 +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]:41517) by ppsw-6.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:nmm1) id 1LQIlv-0002tK-M9 (Exim 4.70) for sc22wg5@open-std.org (return-path ); Fri, 23 Jan 2009 09:56:19 +0000 Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1LQIlv-0005rn-RR (Exim 4.67) for sc22wg5@open-std.org (return-path ); Fri, 23 Jan 2009 09:56:19 +0000 Received: from [83.67.89.123] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.1); 23 Jan 2009 09:56:19 +0000 Date: 23 Jan 2009 09:56:19 +0000 From: "N.M. Maclaren" To: WG5 Subject: Re: [ukfortran] (SC22WG5.3880) (j3.2006) [MPI3 Fortran] MPI non-blocking transfers Message-ID: In-Reply-To: <1232658808.15119.824.camel@math.jpl.nasa.gov> 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> 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 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. >> >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). 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! I don't know what Resolution T7 says. 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