[Mpi-forum] Discussion points from the MPI-<next> discussion today

N.M. Maclaren nmm1 at cam.ac.uk
Sun Sep 23 11:23:31 CDT 2012

On Sep 23 2012, Jed Brown wrote:
>> That can be done only if you impose some OTHER constraints on the use
>> of the buffers, which MPI currently does not do.  I know how to do it,
>> in both Fortran and C99, but I doubt that you do.  The issues for
>> MPI_Ireduce and MPI_Irecv_reduce are far subtler, and I am not even
>> going to try explaining them until you understand the simpler one.
>MPI imposes that the user is forbidden from accessing the buffer until the
>request has completed. The MPI implementation provides the memory barrier
>before returning to the user. Please explain why this is not sufficient?

Because there is no barrier required in the user's code for passive
one-sided communication (though there is for active), and ALL relevant
specifications require both sides to call SOME kind of operation to do
the handshaking.  NONE have one-sided barriers, often not even that the
hardware level.

As a specific example, Fortran compilers can and do move arrays over
procedure calls that do not appear to use them; C ones do not, but are
in theory allowed to.

That problem can be avoided in both languages, but the complications are
so foul that I am not prepared to teach it.  In particular, they involve
arcane programming restrictions on Fortran argument passing and several
widely-used aspects of C, plus subtle use of some of attributes like
TARGET, ASYNCHRONOUS and volatile.  And, heaven help me, at least most
of them really are needed on at least some systems.  The restrictions of
were not introduced just for the hell of it, but because at least some
vendors required them - including effective types :-(

And, as I said, the issues with MPI_Ireduce and MPI_Irecv_reduce are far 
subtler, and are NOT soluble within the language or for all systems.

Nick Maclaren.

More information about the mpi-forum mailing list