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

19 Mar 2012

      Just to make this point clear, maybe we can add the following sentence
to the end of the MPI_ANY_SOURCE paragraph:
  In contrast to the nonblocking case, a blocking receive from
MPI_ANY_SOURCE will complete and raise an error in the class of
MPI_ERR_PROC_FAILED when a process failure occurs in the associated
communicator, and not raise an error in the class of MPI_ERR_PENDING
in this situation.

I agree that, since the point is somewhat muddled in the discussion,
we should explicitly call it out in the case in the paragraph. What do
you all think of the wording above?

I think this would be a good errata item for 3.1.

-- Josh

On Fri, Mar 16, 2012 at 6:15 PM, David Solt <[email protected]> wrote:
...
Since the 2nd paragraph seems to be covering MPI_ANY_SOURCE as a special
case I doubt that a reader would attempt to draw many conclusions about
MPI_ANY_SOURCE from the first paragraph. ï¿½If they did, then the first
sentence could easily be taken as an indication that blocking MPI_ANY_SOURCE
receives will not return an error due to a single process failure because
that failure is not guaranteed to prevent the MPI implementation from
successfully completing the communication. ï¿½ We might intend it to mean that
a blocking recv on MPI_ANY_SOURCE returns an error when a process fails, but
I don't think the text is clear about that. ï¿½ The old text wasn't terribly
clear either, but the catchall "In all other cases, the operation must
return MPI_ERR_PROC_FAILED" ï¿½sort of covered it.
Dave
From: ï¿½ ï¿½ ï¿½ ï¿½Josh Hursey <[email protected]>
To: ï¿½ ï¿½ ï¿½ ï¿½"MPI 3.0 Fault Tolerance and Dynamic Process Control working
Group" <[email protected]>
Date: ï¿½ ï¿½ ï¿½ ï¿½03/16/2012 01:44 PM
Subject: ï¿½ ï¿½ ï¿½ ï¿½Re: [Mpi3-ft] Clarification Ticket 323: MPI_ANY_SOURCE and
ï¿½ ï¿½ ï¿½MPI_Test(any)
Sent by: ï¿½ ï¿½ ï¿½ ï¿½[email protected]
________________________________
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
_______________________________________________
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

Josh Hursey

tags

participants (1)