From owner-sc22wg5@open-std.org Wed Jan 21 12:04:16 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 58D3BC178E7; Wed, 21 Jan 2009 12:04:16 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from ppsw-5.csi.cam.ac.uk (ppsw-5.csi.cam.ac.uk [131.111.8.135]) by www2.open-std.org (Postfix) with ESMTP id CBE10C178E0 for ; Wed, 21 Jan 2009 12:04:09 +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]:49236) by ppsw-5.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.155]:25) with esmtpa (EXTERNAL:nmm1) id 1LPasQ-0004SB-IW (Exim 4.70) (return-path ); Wed, 21 Jan 2009 11:04:06 +0000 Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1LPasQ-0002WN-NS (Exim 4.67) (return-path ); Wed, 21 Jan 2009 11:04:06 +0000 Received: from [83.67.89.123] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.1); 21 Jan 2009 11:04:06 +0000 Date: 21 Jan 2009 11:04:06 +0000 From: "N.M. Maclaren" To: WG5 , MPI-3 Fortran working group Subject: MPI non-blocking transfers Message-ID: 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 There has been a lot of cross-purpose discussion on MPI non-blocking transfers, the ASYNCHRONOUS attribute and related topics. This is an attempt to find out the technical background to people's views, in the hope of reaching a solution. I should particularly like response from implementors, as I believe the main objections are from them. Obviously, I am hoping for detailed technical responses, as this area is a hard one to tie down. Note that this is asking about MPI non-blocking transfers ONLY, and not one-sided ones (which are very different, semantically). Questions: 1) Most people seem to agree that the semantics of the buffers used for MPI non-blocking transfers and pending input/output storage affectors are essentially identical, with READ, WRITE and WAIT corresponding to MPI_Isend, MPI_IRecv and MPI_Wait (and variations). Do you agree with this and, if not, why not? 2) Most people seem to agree that a data attribute is essential, and a purely procedure-based solution will not work. Do you agree with this and, if not, why not? 3) It would be very easy to extend the wording of the ASYNCHRONOUS attribute etc. to allow for asynchronous I/O started and completed by a companion processor (including MPI, here). It would also be very easy to add a new one (say, ASYNCH_EXTERNAL), with the same properties, but applying only to companion processor I/O. Do you think that adding a new attribute is desirable and, if so, why? 4) For Fortran asynchronous I/O, the processor obviously knows when an input/output storage affector becomes and ceases to be pending. From the point of view of program correctness, this information is not needed, but it might be useful for implementors. I proposed such a mechanism, but it seemed to confuse some people. Do you believe that there needs to be a standardised mechanism for the companion processor to inform the Fortran processor of such state changes and, in either case, why or why not? 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