Blocking MPI_ANY_SOURCE receives are covered by the previous paragraph in the proposal: "Future point-to-point communication with the same process on this communicator must also return MPI_ERR_PROC_FAILED." The paragraph that follows after that is just a clarification for a nonblocking receive of MPI_ANY_SOURCE. So I do not think that is an issue. I was mostly trying to figure out if my interpretation of the MPI_Test* functionality was in sync with how others interpreted the text. I think that my interpretation is correct based on my reading of the standard. I do not know if these semantics are a problem for users as long as they are aware of them (that the MPI_Test* functions will not return an error if the nonblocking MPI_ANY_SOURCE receive operation is 'pending'). Since the pending operation can still be matched and completed at some point in the future without the need to clear the error (via failure_ack). I suppose that it seems odd that MPI_Test* would behave this way, and users should be aware. If the program just polls on MPI_Test for completion and never uses MPI_Wait, then they will not get notification of failures that may affect their completion, so they will need to be aware of this situation and find a way to work around it. Seems icky though ('icky' in the technical sense, of course). UTK can you comment on your interpretation of this? -- Josh On Fri, Mar 16, 2012 at 12:06 PM, David Solt <[email protected]> wrote:
I believe I agree with everything you wrote. � �I also believe that our previous draft stated what happens for a blocking MPI_ANY_SOURCE recv ("In all other cases, the operation must return MPI_ERR_PROC_FAILED"), but during our rework of that text we no longer state what happens when a blocking MPI_ANY_SOURCE recv sees a failure.
I'd like to avoid making many changes between our last reading and the first vote because late changes don't inspire confidence, but I think Josh's issue is valid.
Personally I was always in favor of blocking and non-blocking recv on MPI_ANY_SOURCE failing if any process fails. � The recv can complete as failed with the status pointing to the failed process. � The user can still call MPI_Comm_failure_ack to exclude failed ranks from triggering further failures in MPI_ANY_SOURCE. � I don't see the value in MPI_ERR_PENDING. �Reposting the recv is not a big deal and we don't care that much about performance in the failure case. � Still, I'd prefer any change that can address Josh's issue with the least change to the proposal.
Thanks, Dave
From: � � � �Josh Hursey <[email protected]> To: � � � �"MPI 3.0 Fault Tolerance and Dynamic Process Control working Group" <[email protected]> Date: � � � �03/16/2012 08:54 AM Subject: � � � �[Mpi3-ft] Clarification Ticket 323: MPI_ANY_SOURCE and MPI_Test(any) Sent by: � � � �[email protected] ________________________________
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