[Mpi3-ft] Transactional Messages

Richard Graham rlgraham at ornl.gov
Fri Feb 22 21:55:22 CST 2008

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².


On 2/22/08 10:22 PM, "Greg Bronevetsky" <bronevetsky1 at llnl.gov> 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
> bronevetsky1 at llnl.gov
> _______________________________________________
> Mpi3-ft mailing list
> Mpi3-ft at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-ft/attachments/20080222/1149e9de/attachment-0001.html>

More information about the mpiwg-ft mailing list