[Mpi3-rma] current version of proposal

Barrett, Brian W bwbarre at sandia.gov
Wed Mar 2 15:52:07 CST 2011

On 3/2/11 1:50 PM, "James Dinan" <dinan at mcs.anl.gov> wrote:

>On 03/02/2011 01:48 PM, Barrett, Brian W wrote:
>> On 3/2/11 9:47 AM, "James Dinan"<dinan at mcs.anl.gov>  wrote:
>>> When we state that accumulates with the same operation are
>>> non-conflicting, should I be interpreting this as CAS is only
>>> non-conflicting with other CAS operations?  This is a bit of a stretch
>>> since CAS doesn't take an op argument, but I suppose it's doable.  Some
>>> text to help the reader make this connection for CAS would definitely
>>> help.
>> CAS is defined as an accumulate operation (pg 1, ln 38--41), so yes, CAS
>> should be interpreted as a different operation than MPI_REPLACE or
>> or...  I personally think this is obvious, but have no objection to an
>> additional sentence in the accumulate_ops info key specifying this.  I
>> believe that's the only place in the current text where operation
>> conflicts are discussed, but I could be wrong.
>I think there are two ways to interpret the current text:
>1. CAS defines a new accumulate op that can only be performed by
>MPI_Compare_and_swap, thus it is only non-conflicting with itself.
>2. MPI_Compare_and_swap has a fixed op=MPI_REPLACE and it is
>non-conflicting with all other accumulate calls if op=MPI_REPLACE is
>Number 1 seems tricky to me because Get_accumulate with op=MPI_REPLACE
>does an unconditional SWAP.  Number 2 seems to mesh better with existing
>accumulate operations, but do concurrent CAS, SWAP, and REPLACE
>operations play nice?

That's true, I guess I'm ok defining CAS as on MPI_REPLACE operation.
That would mean that you could use CAS, Accumulate(REPLACE),
Get_Accumulate(REPLACE), and Get_Accumulate(NO_OP) to the same address,
with no other operations legal.  That doesn't bother me too much, and
probably makes sense.

As an aside, it's not clear in the current text which is the default for
accumulate_ops: same_op or same_op_no_op.  The semantics section still
defines same_op, but that seems to go agains the use of info keys to relax
requirements on the implementation.


  Brian W. Barrett
  Dept. 1423: Scalable System Software
  Sandia National Laboratories

More information about the mpiwg-rma mailing list