[Mpi-forum] [EXTERNAL] Wording in MPI standard

Brightwell, Ronald rbbrigh at sandia.gov
Tue Nov 27 00:30:33 CST 2012

On Nov 26, 2012, at 2:37 PM, Scott Pakin wrote:

> Ron,
> On 11/26/2012 12:18 PM, Brightwell, Ronald wrote:
>> The issue is not whether the local non-blocking operation will complete, but whether starting a local non-blocking operation is enough to satisfy the matching non-local operation. It  is essentially saying that once an operation has been started and matched, completion is local. That is, completion of a send operation that has been started and satisfied by a matching receive operation (that has also been started) is not dependent on whether that receive operation has been completed. The send side doesn't have to wait for the receive side to call MPI_WAIT in order for the send to complete.
> Yes, I just want the standard to clarify that what you wrote above is
> guaranteed MPI behavior, not simply desirable behavior.

I think it is guaranteed behavior.

> Let me provide a little more detail on what I'm dealing with.  I
> believe, but have not yet managed to prove, that a large LANL
> application is doing something like the following:
>    Rank 0        Rank 1
>    ------        ------
>    ISSEND 1      IRECV 0
>    WAIT          ALLREDUCE
> If MPI guarantees that "the send side doesn't have to wait for the
> receive side to call MPI_WAIT in order for the send to complete"
> (i.e., the non-local matching you refer to), then the preceding
> pseudocode represents a correct use of MPI.  If, however, it would
> merely be "nice" for the send not to have to wait for the receive-side
> MPI_WAIT, then the preceding pseudocode represents an incorrect use of
> MPI that happens to work with all tested MPI implementations but may
> deadlock under some future implementation.

I think this should always work.

>> I'm not sure there's any semantic difference between "... the receive should complete..." versus "... the receive must complete...", but the latter does seem stronger.
> Some standards bodies explicitly distinguish "must" as meaning, "or
> else you don't have a compliant implementation" and "should" as
> meaning, "or else you have a technically compliant but probably poorly
> performing implementation."  The key is whether users can rely on the
> stated behavior for correct application execution, as in my pseudocode
> example above.

I don't think the Standard is usually that subtle about quality of implementation issues, so it seems to me like it should be "must".


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2994 bytes
Desc: not available
URL: <http://lists.mpi-forum.org/pipermail/mpi-forum/attachments/20121127/a0a02d6f/attachment-0001.bin>

More information about the mpi-forum mailing list