(j3.2006) MPI usage problems in Fortran

Aleksandar Donev donev1
Thu Mar 20 13:10:25 EDT 2008


On Thursday 20 March 2008 09:00, Craig Rasmussen wrote:

> Sure.  But what I wanted to do was specify that the target of the
> pointer is asynchronous in the interface. 
There is no such mechanism.

> I don't have a clear way 
> to do this.  If the interface can somehow specify that the target of
> the variable in involved in an asynchronous transaction then the
> compiler can know this without the programmer being required to add
> it as an attribute on the actual (and they will forget to do this).
> It is the role of an interface to specify how a variable will be used.
No, the dummy attributes specify how the dummy is used *inside* the procedure 
and how things are passed. It does not need to, nor should it, indicate 
anything about what happens in the calling scope---that is by definition 
distinct and in control of its own fate.

Now, requiring (via constraints) that the actual has the appropriate attribute 
(asynchronous, target, etc.) is OK. That way users won't forget---the code 
won't compile. Again though, there is no such requirement in the present 
standard (and it cannot be added retroactively).

> declaring a
> dummy argument with the TARGET attribute (and then calling MPI
> routines), doesn't require that TARGET be applied to the effective
> argument of the dummy
TARGET is required in order to use C_LOC to get the address. This is 
independent of whether it is an actual argument, dummy argument, or whatever. 
If you omit TARGET *anywhere* along the call chain, there is no guarantee 
that the address C_LOC returns is actually the address you want (i.e., 
remains valid after the return from MPI_ISend). It could be a copy, it could 
be a temporary array, could be anything. The *only* way to guarantee what is 
needed for MPI_ISend is to have TARGET on the dummy *and* actual, or, have 
POINTER on the dummy *and* POINTER or TARGET on the actual.

> So are either asynchronous or target sufficient to guarantee that buf
> is tainted within the scope of the procedure so that statement
> reordering won't collide with the MPI semantics of the MPI_Wait
> call.
I believe *both* are required. TARGET tells the compiler several things. 
First, it says that the array buffer must actually exist in main memory---it 
cannot be optimized away as some arrays can. That way, it actually has a 
persistent address that you can get with C_LOC and pass to C. It also tells 
the compiler that the buffer can be modified through Fortran or C pointers 
(aliasing). Essentially, it must assume that at any call to a Fortran or C 
procedure or access to a Fortran pointer the buffer might be affected. 
Asynchronous/volatile tells the compiler that things can happen to buffer 
*without* any procedure calls or Fortran pointers being involved. It 
happens "behind the back". This prevents reordering and forces values in 
registers to be refreshed.

> As Bill says, this is very much like asynchronous I/O in 
> Fortran and should be treated similarly.
Yes, but if only ASYNCHRONOUS were itself treated consistently, we could have 
something to work from...

> Perhaps it would be helpful 
> to have the ASYNCHRONOUS attribute apply to procedures, i.e.,
>       ASYNCHRONOUS FUNCTION MPI_Isend(...)
And what exactly does this mean?

Best,
Aleks



More information about the J3 mailing list