Just to follow up, I think that the ³right² thing to do with respect to some sort of transactional model is to have some sort of standard way to request such communications take place ­ probably at init time. We have had such an MPI implementation running in production for several years on a multi-thousand process cluster, and the only thing that needs to be exposed to the users is the ability to turn on/off the functionality ­ all the rest is taken care of just fine within the context of the MPI 2.0 standard, and is 100% standard compliant. This does not deal with hints on the network ³state². Rich On 2/22/08 10:22 PM, "Greg Bronevetsky" <[email protected]> wrote:

...

...

I've read the Transactional Messages proposal and I am a ittle confused here. Is there a reason why we believe that message faults themselves should be handled by the application layer instead of the MPI library? Using the latter model allows one to reduce the error conditions perculated up to the user to revolve around loss of the actual connection to a process (or the actual process itself).

Actually, one aspect of the proposal is that I made sure not to define message faults at a low level. They may be any low-level problems that the implementation cannot efficiently deal with on its own and that are best represented to the application as message drops. One example of this may be process failures. Although we will probably want to define a special notification mechanism to expose those failures to the application, we will also need a way to expose the failures of any communication that involves the process. Another example may be simplified MPI implementations that do not have facilities for resending messages because the probability of an error is rather low and performance is too important. In fact, applications that can tolerate message drops may explicitly choose those MPI implementations for the performance gains.

Greg Bronevetsky Post-Doctoral Researcher 1028 Building 451 Lawrence Livermore National Lab (925) 424-5756 [email protected] _______________________________________________ Mpi3-ft mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft