(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