[Mpi3-rma] Updated MPI-3 RMA proposal 1

[Underwood, Keith D]

Well, I'm sorry that I couldn't be there.  I believe that adding both of these could be the death knell for proposal 1.  They will both be extremely contentious.  Adding all_flush_all to passive target is adding an active target-like call, which is ugly from an API design perspective.  Allowing multiple locks invites deadlock from the user.

Do we have the use cases for both of those and some attempt at quantification of the performance advantage in some implementation?  Everything else in proposal 1 either adds semantics that are necessary to make some use case possible, adds a demonstrable scalability advantage, or gives a quantifiable performance gain for a use case.  

Keith

> -----Original Message-----
> From: mpi3-rma-bounces at lists.mpi-forum.org [mailto:mpi3-rma-
> bounces at lists.mpi-forum.org] On Behalf Of Torsten Hoefler
> Sent: Wednesday, June 16, 2010 5:46 PM
> To: mpi3-rma at lists.mpi-forum.org
> Subject: [Mpi3-rma] Updated MPI-3 RMA proposal 1
> 
> Hi All,
> 
> After the meeting, I updated the proposal to allow for multiple locks
> (I
> removed the only sentence that forbids it). I also added all_flush_all
> as we discussed in the meeting.
> 
> I didn't find any more places that mention the lock restrictions. But
> please check for consistency.
> 
> See attached file at:
> https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/RmaWikiPage
> 
> Thanks & All the Best,
>   Torsten
> 
> --
>  bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ -----
> Torsten Hoefler         | Modeling and Simulation Lead
> Blue Waters Directorate | University of Illinois
> 1205 W Clark Street     | Urbana, IL, 61801
> NCSA Building           | +01 (217) 244-7736
> _______________________________________________
> mpi3-rma mailing list
> mpi3-rma at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma