From: lusk@donner.mcs.anl.gov (Rusty Lusk)
Newsgroups: comp.parallel.mpi
Subject: Re: [Q] Out-of-order calls in MPI vs. PVM
Date: 28 Jun 1999 15:41:59 GMT
Organization: Argonne National Laboratory
Message-Id: <7l8547$qh0$1@milo.mcs.anl.gov>
References: <7l0u34$q9g$1@mozo.cc.purdue.edu>
Xref: ukc comp.parallel.mpi:5255


In article <7l0u34$q9g$1@mozo.cc.purdue.edu>, jonesbr@roger.ecn.purdue.edu (Brian R. Jones) writes:
|> A node has a message pending for receipt, but can't post the receive
|> until after sending off another message.  The buffering supplied by
|> the PVM daemon will allow this behavior, while the MPI code must be
|> structured to handle the MPI commands in the order that they occur.
|> Am I interpreting this correctly?  Is the simple (but ugly) solution
|> to add MPI_Probe commands before each send to test for a pending
|> receive?

The program as you describe it is what MPI calls an "unsafe" program,
in that its correctness depends on the amount of system buffering and
the sizes of the messages.  This is true even for the PVM version,
although PVM may be giving you adequate buffering for your message sizes.
MPI implementations vary from parsimonious to generous in the amount of
buffering they supply in various situations.  The best approach is to make
your program safe.

There are several ways to write a safe program in MPI.  You can 

1.  carefully order the sends and receives, so that the interchange looks
    like this:

      Process 0           Process 1
      ---------           ---------
       MPI_Send            MPI_Recv
       MPI_Recv            MPI_Send


2.   use the MPI_Sendrecv function, like this:

      Process 0           Process 1
      ---------           ---------
     MPI_Sendrecv        MPI_Sendrecv


3.   or use the non-blocking operations, like this:

      Process 0           Process 1
      ---------           ---------
       MPI_Irecv           MPI_Irecv
       MPI_Isend           MPI_Isend
       MPI_Waitall         MPI_Waitall

The first alternative is cumbersome in dimensions greater than 1.  The
second alternative is just a compact version of the third.  The third
generalizes to exchanges with larger numbers of neighbors.

Rusty Lusk