From owner-sc22wg5@open-std.org Fri Jan 23 12:46:41 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 52FA8CA5FFA; Fri, 23 Jan 2009 12:46:41 +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 9773FCA5FED for ; Fri, 23 Jan 2009 12:46:39 +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]:46687) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:nmm1) id 1LQKUh-0003mF-Mf (Exim 4.70) for sc22wg5@open-std.org (return-path ); Fri, 23 Jan 2009 11:46:39 +0000 Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1LQKUh-00066V-0G (Exim 4.67) for sc22wg5@open-std.org (return-path ); Fri, 23 Jan 2009 11:46:39 +0000 Received: from [131.111.10.32] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.1); 23 Jan 2009 11:46:39 +0000 Date: 23 Jan 2009 11:46:39 +0000 From: "N.M. Maclaren" To: WG5 Subject: Re: [ukfortran] (SC22WG5.3905) (j3.2006) [MPI3 Fortran] [MPI3 Fortran] MPI non-blocking transfers Message-ID: In-Reply-To: <20090122221841.2ACCACA5FE6@www2.open-std.org> References: <20090122100652.C31E9CA3434@www2.open-std.org> <4978A8A0.8090407@cray.com> <20090122175730.8BA1BCA3439@www2.open-std.org> <4978C20F.2070207@cray.com> <20090122214202.3AB89CA5FE6@www2.open-std.org> <20090122221841.2ACCACA5FE6@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 22 2009, Jim Xia wrote: > >Sad to say, but true to some compiler writers: asynchronous alone will >have no impact on how the procedure call is dealt with (or optimized). >Asynchronous attribute will only take effect when there is a corresponding >WAIT statement somewhere due to the "invisible hands" referred to by Bill. > I think asynchronous approach to nonblocking transfer may lead to >nowhere, at least not as easy as it appears. I know that is is politically difficult, and finding out what people believed was the purpose of starting this thread. But, if some people are going to reject any technically possible solution, then there is a very big problem. And, so far, nobody has proposed anything except that which has any technical plausibility - all of the alternatives will work only if the programmer uses MPI in a particular way. Unless this one is resolved, the current situation will continue, and users who have problems will quite rightly claim that the reason is that Fortran is an inadequate language. That is a pity. 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