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

[Underwood, Keith D]

> This ship has sailed.  You're the only person who has voiced an objection to all_flush_all and numerous others 
> have demonstrated at length why it is necessary.  I do not find the obsession with pure-passive target 
> semantics to be a compelling reason to reject all_flush_all.

All_flush_all will further dissuade good implementations of passive-target semantics.  To my understanding, many implementations don't provide compliant passive-target semantics now and the introduction of all_flush_all will give another out to those implementations.  So, yeah, call me a purist, but it isn't JUST about doing API design that looks reasonable and has reasonable names.

> > Do we have the use cases for both of those and some attempt at
> > quantification of the performance advantage in some implementation?
> 
> Yes.  I will not repeat the use case for all_flush_all since we have
> discussed that topic far too long already.  Somewhat else should
> present the multiple locks issue generically before I give the Global
> Arrays use case.

I have REPEATEDLY asked for a quantification of the advantage, and NOBODY has offered a quantitative discussion.  Lots of hand waving and discussion of challenges that are faced on BG, even an interesting implementation case given by Brian Smith, but he agreed that there would be a crossover where all_flush_all could be slower than flush_all + barrier, since there is an iteration that is involved.  And, right now, there is only one system I know of where there is an opportunity for an advantage: BG.  So, many of us CAN'T quantify the advantage.

Keith