Yes, MPI_ERR_PENDING is a good example! So we're not entering new territory by giving an "error" for an active request. -d On Oct 13, 2011, at 9:46 AM, Josh Hursey wrote:
By returning an error we are completing the ANY_SOURCE request - isn't that the problem we are trying to work around. The problem was that ANY_SOURCE would complete in error causing the matching issues.
That is unless you are suggesting that we give the error the same semantics as MPI_ERR_PENDING. MPI_ERR_PENDING kinda works like a warning. For wait_all, the non-completed messages have a status.MPI_ERROR = MPI_ERR_PENDING to indicate that they are still outstanding, and need to be waited on. This way the user can distinguish between requests that are complete (either successfully or in error) and those that are not complete yet. So if we have a different error with similar semantics, e.g., MPI_ERR_ANY_SOURCE_DISABLED, we can say that it is similar to MPI_ERR_PENDING in that the request is not complete. The user can then decide to continue waiting or cancel the request. Is that what you were thinking?
-- Josh
On Tue, Oct 11, 2011 at 4:24 PM, Darius Buntinas <[email protected]> wrote:
I think we can do this without a warning, just by using an error: If a wait (or wait_all, test, etc) is called with an anysource request while the req's communicator is anysource disabled, then the function will return an error (maybe something like MPI_ERR_ANYSOURCE_DISABLED).
Of course in the wait_all case the app needs to be able to determine which req is the anysource on a disabled communicator. We may be able to help the user here by using the status array.
-d
On Oct 11, 2011, at 3:16 PM, Darius Buntinas wrote:
I think you're right Josh, the blocking version wouldn't need to be changed.
For the nonblocking version, wouldn't we only need to lock around the Wait, not between the Recv and Wait? If we're worried about hanging in a blocking Wait, I think we just need to check for all-clients-failed before calling Wait. If anysources are reenabled by another thread before this thread calls Wait, that's OK, so long as the thread checks first.
Here's a function a user could implement to use whenever waiting on an anysource:
int My_AS_MPI_Wait(MPI_Request *req, MPI_Status *status) { while(1) { reader_lock(); if (my_cnt != recognize_cnt) { /* New failures were detected */ /* check failed_group and decide if ok to continue */ if (ok_to_continue(req, failed_group) == FALSE) { reader_unlock(); return MPI_ERR_PROC_FAIL_STOP; } my_cnt == recognize_cnt; } err = MPI_Wait(req, status); if (err == MPI_WARN_PROC_FAIL_STOP) { /* Failure case */ reader_unlock(); writer_lock(); if (my_cnt != recognize_cnt) { /* another thread has already re-enabled wildcards */ writer_unlock(); continue; } MPI_Comm_reenable_any_source(comm, &failed_group); ++recognize_cnt; writer_unlock(); continue; } else { reader_unlock(); return MPI_ERR_PROC_FAIL_STOP; } reader_unlock(); } }
-d
_______________________________________________ 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
participants (1)
-
Darius Buntinas