[MPI3 Fortran] MPI non-blocking transfers

Bill Long longb at cray.com
Wed Jan 21 12:48:23 CST 2009

Aleksandar Donev wrote:
> Hi Bill,
>> Having the buffer automatically acquire this new attribute is
>> necessary if we want to avoid requiring changes to existing codes.
> This is raising red flags for me. Existing codes are *buggy*, and trying 
> to somehow make them conforming and well-behaved seems doomed to me. 

Well, that's a point for discussion.  Is it a goal to avoid requiring 
user source code changes?  How important is this issue?  This is 
something for MPI folks to decide.  (This is a pretty basic question 
that probably should have been in the original list.)

>>>    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?
>> The question hints at a common confusion. 
> Please answer the actual question.

I would have if the question were well-formed.  It was not.  I was just 
trying to explain the situation as clearly as possible.  I'm looking at 
this from a vendor perspective.  There are two issues that have separate 
solutions.   Failing to understand this resulted in some 
bandwidth-wasting email recently, and I'm trying to head off more of the 

>>  Various solutions to
>> this problem have been discussed, most centering on an attribute for
>> dummy arguments
> If so, your answer to question 2 is yes?
>> or coding versions of the MPI routines that accept 
>> pass-by-descriptor rather than
>> pass-by-address for the buffer argument.
> Answer to question 2 is no---something new is proposed. Are you 
> proposing something new or do you prefer an ASYNCH_EXTERNAL attribute? 

I'm open to either approach.  This is something the MPI folks need to 
decide. Are they willing to have a completely different library 
interface for Fortran? 

> Or maybe you prefer not to do anything at all (i.e., ignore the issue).

Considering that people have been using MPI with considerable success 
for a very long time, that is one option.  However, the discussion 
presupposes that facilities to reduce possible user problems are 
desired, so either you accept the premise or drop out of the discussion.


Bill Long                                   longb at cray.com
Fortran Technical Support    &              voice: 651-605-9024
Bioinformatics Software Development         fax:   651-605-9142
Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120


More information about the mpiwg-fortran mailing list