[Mpi3-rma] current version of proposal

[Torsten Hoefler]

On Wed, Mar 02, 2011 at 02:52:07PM -0700, Barrett, Brian W wrote:
> 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
> >>MPI_SUM
> >> 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
> >given.
> >
> >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.
True. Right now, the stricter (more limited) semantics are default (I
don't have an issue with this). We could forward-reference from the
info-key description to the semantics section to make it more clear.

All the Best,
  Torsten

-- 
 bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ -----
Torsten Hoefler         | Performance Modeling and Simulation Lead
Blue Waters Directorate | University of Illinois (UIUC)
1205 W Clark Street     | Urbana, IL, 61801
NCSA Building           | +01 (217) 244-7736