From owner-sc22wg5@open-std.org Sat Jan 24 05:20:26 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 B8B98CA6002; Sat, 24 Jan 2009 05:20:26 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from nspiron-2.llnl.gov (nspiron-2.llnl.gov [128.115.41.82]) by www2.open-std.org (Postfix) with ESMTP id CD0C1C178D9 for ; Sat, 24 Jan 2009 05:20:24 +0100 (CET) X-Attachments: None Received: from vpna-user-128-15-244-77.llnl.gov (HELO [128.15.244.77]) ([128.15.244.77]) by nspiron-2.llnl.gov with ESMTP; 23 Jan 2009 20:20:23 -0800 Message-ID: <497A9707.2070308@llnl.gov> Date: Fri, 23 Jan 2009 20:20:23 -0800 From: Aleksandar Donev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.8) Gecko/20071009 SeaMonkey/1.1.5 MIME-Version: 1.0 To: MPI-3 Fortran working group Cc: WG5 Subject: Re: [MPI3 Fortran] (j3.2006) (SC22WG5.3917) (SC22WG5.3909) [ukfortran] [MPI3 Fortran] MPI non-blocking transfers 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> <20090123095622.CBD80CA5FED@www2.open-std.org> <20090123190515.A5B24CA5FE6@www2.open-std.org> <497A1CE5.3000708@cray.com> <20090123204209.615C8CA5FED@www2.open-std.org> <1232747203.15119.979.camel@math.jpl.nasa.gov> In-Reply-To: <1232747203.15119.979.camel@math.jpl.nasa.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-sc22wg5@open-std.org Precedence: bulk Van Snyder wrote: > Just write an extra layer to get at MPI_wait, having an assumed-shape > buffer dummy argument with the ASYNCHRONOUS attribute and without the > CONTIGUOUS attribute. Since the buffer dummy won't be referenced, make > the procedure external, or better yet, write it in C, so a clever > optimizer won't inline it, notice the buffer isn't used, and then move > accesses to the buffer across the remaining reference to MPI_wait, which > is the present problem. > > Make this layer generic with MPI_wait. Tell users to put the buffer or > something associated with it, if one is in scope, as the associated > actual argument, and tell them why. If there were an emoticon for throwing up in disgust I would put it here! This is horrid. Why don't you just tell the user "don't use asynchronous data transfers"??? > Since we already have a solution, I don't see the need for another one, Well I do, since your solution is such a mess it is not really a solution. Yes, you can do HACKs. That is NOT a "solution". Best, Aleks