[Mpi3-rma] RMA proposal 1 update

[Underwood, Keith D]

> 1:34 - Need to add MPI_Get_accumulate

And compare and swap...

1:41 - is there really an advantage to changing the wording there?  What does that gain us other than a diversionary argument?
 
> 6:14 - Add MPI_Get_accumulate
> 
> 6:44 - Same

And compare-and-swap

> 14:16 - Are derived datatypes allowed in MPI_Get_accumulate? If so, we
> could as well allow a count argument here.

We generally need to decide what to do with datatypes there.  I thought we wanted to (at most liberal) use the ACCUMULATE language:

Each datatype argument must be a predefined datatype or a derived datatype, where
all basic components are of the same predefined datatype. Both datatype arguments must
be constructed from the same predefined datatype. The operation op applies to elements of
that predefined type. target_datatype must not specify overlapping entries, and the target
buffer must fit in the target window.

The question is then whether we allow more than one predefined datatype.  For any rational semantics with any hope of efficiency, I don't see how we can allow more than one element of a predefined datatype.  I.e. MPI_Get_accumulate allows two accesses to target the same memory location and defines operation interleaving.  I don't think the user is going to expect what they get if we allow more than one element.  E.g. multiple ops target one location... one of them gets applied first for the first item, a second one gets applied first for the second, a third one... etc.  

16:47-17:1 - I don't like the mnemonics for IDENTICAL and SMALLER.  Why not the traditional equal and less? 

We are going to need updates to the memory model description for Get_accumulate.  Specifically, the return+op has to be performed atomically.  That is, you cannot return one value, have another accumulate or get_accumulate applied, and then apply your op.  

Keith