[Mpi3-ft] Clarification Ticket 323: MPI_ANY_SOURCE and MPI_Test(any)

Josh Hursey jjhursey at open-mpi.org
Fri Mar 16 08:52:42 CDT 2012


I believe my reasoning is correct below, but thought I would ask the
group to confirm.

Consider the following code snippet:
---------------------
MPI_Irecv(..., MPI_ANY_SOURCE, ..., &req);
/* Some other process in the communicator fails */
MPI_Test(&req, &flag, &status);
---------------------

The proposal in #323 says that the request should be marked as
MPI_ERR_PENDING and not complete. So what should the value of 'flag'
and 'status' be when returning from MPI_Test?

According to the standard, 'flag = true' indicates two things:
1) the operation is completed
2) The 'status' object is set

For the MPI_ANY_SOURCE case above, the operation is -not- completed,
so (1) is violated; therefore I think MPI_Test should set 'flag' equal
to 'false'. However, is the 'status' also not set? Should MPI_Test
return MPI_SUCCESS or MPI_ERR_PENDING?

If MPI_Test is to return MPI_ERR_PENDING directly, then there is no
needed to inspect 'status'. However if we replace MPI_Test with
MPI_Testany(1, &req, &index, &flag, &status) then the operation would
return MPI_ERR_IN_STATUS, and the user must inspect the 'status' field
for the true error value. So we would still set 'flag = false', but
would also need to set the 'status'. That is if we want MPI_Test*
return an error code that indicates that the request as 'failed, but
not completed'.

According to the standard, if no operation is completed then
MPI_Testany "returns flag = false, returns a value of MPI_UNDEFINED in
index and status is undefined." So according to the MPI_Testany logic,
in this case 'flag = false', 'status is undefined', and the operation
should return MPI_SUCCESS. Is that the expected behavior for the code
snippet above?

I think so, but I thought I would double check with the group.

This means that the user can only 'see' the MPI_ERR_PENDING state of
the request when they call an MPI_Wait* operation, which might not be
what they would normally want to do (because they do not want to
block).

-- Josh

-- 
Joshua Hursey
Postdoctoral Research Associate
Oak Ridge National Laboratory
http://users.nccs.gov/~jjhursey



More information about the mpiwg-ft mailing list