[Mpi3-ft] Piggybacking API

Martin Schulz schulzm at llnl.gov
Mon Apr 21 13:47:10 CDT 2008

At 06:36 AM 4/21/2008, Terry Dontje wrote:
>So I reread the piggybacking document on wiki.  I am not thrilled with
>the amount of new APIs this would be adding to the standard but can also
>see the point of the paper.  I am curious how the new API is expected to
>be used?  The proposal say's this API is needed for user-level fault
>tolerance solutions.  So do we expect a user to change all application
>calls to the MPI library to use the PB calls?  I wonder if a more
>general solution that doesn't require a direct change to the API would work.

Layers like the one for fault tolerance will have to intercept
all MPI communication calls anyway (otherwise it will not be
possible to capture the state of the MPI layer) and hence the
most likely mechanism to implement them is the PMPI layer. At
this point it will be very easy and fully transparent to also
replace communication calls with the piggyback counterparts.
The application would not see the difference (if we get the API
right :) ).

>I wonder if there might be a way one could register piggybacking with a
>communicator and somehow have the actual piggybacking occur as a
>callback from an implementations messaging layer?

Registering piggyback data beforehand (whether per communicator
or globally) has the problem that in a fully multithreaded use
of MPI piggyback data can no longer be associated with a single
MPI call/message (unless we make the piggyback data thread local,
but this would require a concept of threads in MPI and I don't
think we should go there).


>Just a thought,
>mpi3-ft mailing list
>mpi3-ft at lists.mpi-forum.org

Martin Schulz, schulzm at llnl.gov, http://people.llnl.gov/schulz6
CASC @ Lawrence Livermore National Laboratory, Livermore, USA  

More information about the mpiwg-ft mailing list