<font size=2 face="sans-serif">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. </font>
<br>
<br><font size=2 face="sans-serif">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. </font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">Thanks,</font>
<br><font size=2 face="sans-serif">Dave</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Josh Hursey <jjhursey@open-mpi.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">"MPI 3.0 Fault
Tolerance and Dynamic Process Control working Group" <mpi3-ft@lists.mpi-forum.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">03/16/2012 08:54 AM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">[Mpi3-ft] Clarification
Ticket 323: MPI_ANY_SOURCE and MPI_Test(any)</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Sent by:
</font><font size=1 face="sans-serif">mpi3-ft-bounces@lists.mpi-forum.org</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>I believe my reasoning is correct below, but thought
I would ask the<br>
group to confirm.<br>
<br>
Consider the following code snippet:<br>
---------------------<br>
MPI_Irecv(..., MPI_ANY_SOURCE, ..., &req);<br>
/* Some other process in the communicator fails */<br>
MPI_Test(&req, &flag, &status);<br>
---------------------<br>
<br>
The proposal in #323 says that the request should be marked as<br>
MPI_ERR_PENDING and not complete. So what should the value of 'flag'<br>
and 'status' be when returning from MPI_Test?<br>
<br>
According to the standard, 'flag = true' indicates two things:<br>
1) the operation is completed<br>
2) The 'status' object is set<br>
<br>
For the MPI_ANY_SOURCE case above, the operation is -not- completed,<br>
so (1) is violated; therefore I think MPI_Test should set 'flag' equal<br>
to 'false'. However, is the 'status' also not set? Should MPI_Test<br>
return MPI_SUCCESS or MPI_ERR_PENDING?<br>
<br>
If MPI_Test is to return MPI_ERR_PENDING directly, then there is no<br>
needed to inspect 'status'. However if we replace MPI_Test with<br>
MPI_Testany(1, &req, &index, &flag, &status) then the operation
would<br>
return MPI_ERR_IN_STATUS, and the user must inspect the 'status' field<br>
for the true error value. So we would still set 'flag = false', but<br>
would also need to set the 'status'. That is if we want MPI_Test*<br>
return an error code that indicates that the request as 'failed, but<br>
not completed'.<br>
<br>
According to the standard, if no operation is completed then<br>
MPI_Testany "returns flag = false, returns a value of MPI_UNDEFINED
in<br>
index and status is undefined." So according to the MPI_Testany logic,<br>
in this case 'flag = false', 'status is undefined', and the operation<br>
should return MPI_SUCCESS. Is that the expected behavior for the code<br>
snippet above?<br>
<br>
I think so, but I thought I would double check with the group.<br>
<br>
This means that the user can only 'see' the MPI_ERR_PENDING state of<br>
the request when they call an MPI_Wait* operation, which might not be<br>
what they would normally want to do (because they do not want to<br>
block).<br>
<br>
-- Josh<br>
<br>
-- <br>
Joshua Hursey<br>
Postdoctoral Research Associate<br>
Oak Ridge National Laboratory<br>
</font></tt><a href=http://users.nccs.gov/~jjhursey><tt><font size=2>http://users.nccs.gov/~jjhursey</font></tt></a><tt><font size=2><br>
_______________________________________________<br>
mpi3-ft mailing list<br>
mpi3-ft@lists.mpi-forum.org<br>
</font></tt><a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft"><tt><font size=2>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft</font></tt></a><tt><font size=2><br>
<br>
</font></tt>
<br>