From owner-sc22wg5@open-std.org Wed Nov 12 21:47:03 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 498E2CA343B; Wed, 12 Nov 2008 21:47:03 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from ppsw-7.csi.cam.ac.uk (ppsw-7.csi.cam.ac.uk [131.111.8.137]) by www2.open-std.org (Postfix) with ESMTP id 43AB7C178D9 for ; Wed, 12 Nov 2008 21:47:01 +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-1.csi.cam.ac.uk ([131.111.8.51]:48613) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:nmm1) id 1L0Mc9-0000LP-NH (Exim 4.70) for sc22wg5@open-std.org (return-path ); Wed, 12 Nov 2008 20:47:01 +0000 Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1L0Mc9-00011a-6c (Exim 4.67) for sc22wg5@open-std.org (return-path ); Wed, 12 Nov 2008 20:47:01 +0000 Received: from [83.67.89.123] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.1); 12 Nov 2008 20:47:01 +0000 Date: 12 Nov 2008 20:47:01 +0000 From: "N.M. Maclaren" To: WG5 Subject: Re: [ukfortran] (SC22WG5.3660) (j3.2006) N1755: Request for new features from MPI Forum Message-ID: In-Reply-To: <20081111214622.271B9C178D6@www2.open-std.org> References: <49137AD3.1070402@lrz.de> <20081111181417.B7A22C178D6@www2.open-std.org> <20081111192352.ED310C178D6@www2.open-std.org> <20081111214622.271B9C178D6@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 Nov 11 2008, Aleksandar Donev wrote: > >> This one is very simple, anyway. As far as the program is concerned, MPI >> transfers are semantically just a specialised form of I/O. Does anyone >> seriously dispute that? > > I am not, obviously I proposed to extend the already existing mechanisms > we have for async Fortran I/O to cover user-defined data transfers. Upon thinking it over, I think that it's even simpler than I thought. And I am even more firmly of the view that the right attribute is ASYNCHRONOUS and not VOLATILE - the latter is toxic in all languages that have it. All that really needs saying (in Fortran) is that a companion processor can set and clear the pending attribute and create an ID in a processor dependent fashion. MPI then needs to say that it does precisely that - MPI is a perfectly respectable companion processor, after all! If an implementor can't get it right after that, he or she is beyond redemption. Now, tying that up in standardsese is not not easy :-( 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