[Mpi3-ft] Summary of today's meeting

[Greg Bronevetsky]

>Can someone think of a reason to have the library do this over the 
>app ?  I can see that letting the library do this will avoid 
>potential race conditions that could arise if we let the app do this 
>- basically out of band with respect to the expected communications traffic.
The application can implement this functionality by having somebody 
write the appropriate notification protocol as a PMPI layer and just 
plugging it in between the application and MPI. If we have 
piggybacking, this layer will also be fairly efficient. The only 
issue may be that piggybacking over collectives is hard to define, 
putting a limit on how efficient such application-level protocols 
will be. However, the fact is that different people will want MPI to 
provide many more services and protocols than MPI vendors can 
actually implement. As such, we're much better off putting together a 
robust and efficient piggybacking API than asking for more services 
to be implemented on top of the library.

Greg Bronevetsky
Post-Doctoral Researcher
1028 Building 451
Lawrence Livermore National Lab
(925) 424-5756
bronevetsky1 at llnl.gov 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-ft/attachments/20081023/a0df8b7d/attachment-0001.html>