[Mpi3-ft] New revision of RTS proposal

Josh Hursey jjhursey at open-mpi.org
Fri Dec 16 14:36:48 CST 2011


A new version of the document is available on the following wiki page:
  https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/ft/rts_proposal_main

We have to have this document finalized by COB Monday if at all
possible. So take a look at it and send feedback to the list.

-- Josh

Change Log:
-----------
 * Fix a few typos
 * 17.5.1: Update the Process Failure handler section per discussions
 * 17.6: Touch up the MPI_ANY_SOURCE wording
 * 17.6: Clarify that if MPI_Comm_reenable_any_source is called with
an intercommunicator then it returns the group of failed processes in
the remote group.
 * 17.6: Advice to implementors that MPI_Comm_drain maybe a locally
collective operation.
 * 17.6: Extend advice to users to note that MPI_FAILHANDLER_MODE_ALL
does not guarantee that the failure handler will be called the same
number of times unless they call a validation operation to synchronize
the handlers. So they need to take care when using MPI_Comm_drain() in
this operating mode.
 * 17.6.1: Add a sentence allowing MPI_ERR_IN_STATUS to be returned
from test and completion operations even if it is just the
MPI_ERR_ANY_SOURCE_DISABLED warning.
 * 17.8.2: Communicator creation must have a collectively active input
communicator, and return uniformly at all processes.
 * 17.8.2: Communicator construction operations will match across
process failure. So they match similar to MPI_Comm_validate() and not
like other collectives.
 * 17.8.3: Inter-communicator creation operations have the same
constraints as communicator creation (Previous 2 points).
 * 17.8.4: Added example section with the communicator creation loop example.
 * 17.9: Topology creation operations match semantics of communicator creation.
 * 17.10: Dynamic creation operations (spawn and friends) match
semantics of communicator creation.
 * 17.11: Window creation operations match semantics of communicator creation.
 * 17.12.2: File_open/close match semantics of communicator creation.
 * A.1.1: Added the MPI_FAILHANDLER_MODE_*'s to the appendix

Open Discussion Items:
----------------------
 * 17.6: Rename MPI_Comm_reenable_any_source to *_validate_* (?)
 * 3.10 & 17.6.2 : Do these sections conflict? Should the status only
be associated with the 'source' since MPI_Recv would have returned the
status value if the operations were called separately?


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



More information about the mpiwg-ft mailing list