I agree that these should be the expected semantics. However, I do not know how an MPI implementor would reach this conclusion from the proposed standard+ticket 323. But maybe I missed some connecting thread in the proposal. As you point out, the error case is not well defined in the current standard. So the proposal should clarify this so that implementors provide the correct functionality to the users, and the users know what they are programming against. If we conclude that a clarification is necessary, I think this is a good errata item for 3.1. Just a clarification to the MPI_Test* functionality. If you all agree, can you provide some suggested wording for this errata item? Thanks, Josh On Fri, Mar 16, 2012 at 4:55 PM, George Bosilca <[email protected]> wrote:

The expected behavior is straightforward:

- MPI_Test is a single completion function, it will therefore return MPI_ERR_PENDING, without setting flag to true or affecting the status.

- If MPI_Test is replaced by MPI_Testany, then the operation will return MPI_ERR_IN_STATUS, the index will be set, the flag will not be set, and the status will be updated. All multiple completion function will behave similarly (setting the status->error to MPI_ERR_PENDING) and returning MPI_ERR_IN_STATUS.

You are right, as no operation is completed, the flag will remain set to false. However, we are in the case where the MPI_Testany is returning an error, case that is not well defined in the current standard.

�george.

On Mar 16, 2012, at 09:52 , Josh Hursey wrote:

...

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 _______________________________________________ mpi3-ft mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft

_______________________________________________ mpi3-ft mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft

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