From owner-sc22wg5@open-std.org Thu Jan 22 01:04:07 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 B4AA4CA3439; Thu, 22 Jan 2009 01:04:07 +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 9FDE5CA3434 for ; Thu, 22 Jan 2009 01:04:05 +0100 (CET) Received: from mprox3.jpl.nasa.gov (mprox3.jpl.nasa.gov [137.78.160.171]) by mail.jpl.nasa.gov (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n0M043Ed002787 for ; Thu, 22 Jan 2009 00:04:03 GMT Received: from [137.79.7.57] (math.jpl.nasa.gov [137.79.7.57]) (authenticated bits=0) by mprox3.jpl.nasa.gov (Switch-3.2.6/Switch-3.2.6) with ESMTP id n0M041Ui017906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 21 Jan 2009 16:04:02 -0800 Subject: Re: (j3.2006) (SC22WG5.3879) [ukfortran] [MPI3 Fortran] MPI non-blocking transfers From: Van Snyder Reply-To: Van.Snyder@jpl.nasa.gov To: WG5 In-Reply-To: <20090121234200.4F3BDCA3434@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> Content-Type: text/plain Organization: Yes Date: Wed, 21 Jan 2009 16:04:01 -0800 Message-Id: <1232582641.15119.692.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 Wed, 2009-01-21 at 15:41 -0800, N.M. Maclaren wrote: > On Jan 21 2009, Aleksandar Donev wrote: > > > >> As someone with experience of installing and supporting multiple > >> different MPI's on multiple different systems, it is thoroughly > >> undesirable. > > > >Anyone on the Fortran committee should find it "undesirable" that we > >have a problem we know about, that can be solved, appears in many > >codes, and is usually attributed to the language (instead of the MPI > >Forum). We ought to fix this. It is simply our duty as the guardians of > >the language. > > Yes. Equally seriously, the existing 'solutions' require all MPI programs > that use the non-blocking calls to rely on undefined behaviour, that may > (but is not required to be) supported by the processor by the use of > compiler options (or otherwise). That's not acceptable in a reasonable > language standard. Does the problem arise because the buffer doesn't appear as an actual argument in the call to the MPI wait routine, or is there another cause for it? Assuming the problem is caused by the buffer not appearing as an actual argument, it's not a defect in Fortran but rather in the design of MPI. 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. When compiling the calling routine, the compiler can only see the interface of the called routine, not all of its guts, so it doesn't know whether the called routine actually contains an asynchronous I/O statement or WAIT statement, or if there's one somewhere down its call tree -- and it doesn't and can't care. So what's the difference if the wait is inside the MPI library?