[MPI3 Fortran] Fortran extra_state argument to MPIattributefunctions

Bill Long longb at cray.com
Thu May 28 12:17:13 CDT 2009

Besides the more formal methods mentioned by Aleks below, there is a 
common programming style approach to solve this problem: put the 
variable extra in a module.  The compiler has to assume that any 
non-intrinsic procedure reference might access the module, and hence 
access or modify the variable.  This technique generally avoids 
performance hits  that might be associated with some others - in 
particular, the VOLATILE attribute can shut down almost all optimization 
for a variable.

I would note that this is a general problem when calling library 
routines (typically written in C) that stash a copy of a pointer for 
later use in a different routine. This is not isolated to MPI.  I 
recently saw the same issue with the fftw package.  Using a module 
solved that person's problem.


Aleksandar Donev wrote:
> Ian asked:
>>  > Is there a standard-conformant way to indicate that extra may be 
>> accessed
>>  > or modified during the calls to mpi_comm_dup and mpi_comm_free?
> And Jim responded:
>> Not now.
> This is incorrect. There are ways to do what Ian asks for above, in 
> fact, two attributes cover it, notably, TARGET and VOLATILE or a 
> combination of both. The right one in this context is the TARGET 
> attribute. Your array extra *must* have the TARGET attribute. In fact, 
> using C interop as I suggested and thus using C_LOC, requires the 
> attribute (I am sure the vendor exentsion LOC doesn't because 
> extensions don't worry about fine details like this---this is why we 
> usually turn them down in the committee!).
> It is perfectly legal in Fortran 95, and all subsequent versions, for 
> a routine to save a pointer to a TARGET, and then later use it during 
> a call to a procedure. Unless the compiler can prove otherwise, it is 
> not allowed to move code past calls to unknown routines, since it does 
> not know whether targets are affected.
> What is not allowed or supported, and is needed for non-blocking 
> communication, is to modify the array extra while the Fortran code is 
> executing (asynchronously), not necessarily during a procedure call. 
> If you put a VOLATILE argument that will be handled too. But it will 
> also make any use of the said array inefficient.
> To repeat: Jim, this is a separate issue from ASYNCHRONOUS data 
> transfers and should not be mixed under that banner.
> Best,
> Aleks
> _______________________________________________
> mpi3-fortran mailing list
> mpi3-fortran at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran

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