[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.
Cheers,
Bill
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