[Mpi3-rma] RMA op compatibility matrix

[Pavan Balaji]

Jim,

The table looks fine, except what you call MPI-3 should be MPI-3 
UNIFIED. MPI-3 SEPARATE should be the same as MPI-2.

  -- Pavan

On 10/14/2011 05:21 PM, James Dinan wrote:
> I am pretty sure that this rule is meant to apply to both the one-window
> and multiple-windows cases.  The rationale that follows seems to confirm
> this:
>
> --snip--
>
> Rationale. The last constraint on correct RMA accesses may seem unduly
> restrictive, as it forbids concurrent accesses to nonoverlapping
> locations in a window. The reason for this constraint is that, on some
> architectures, explicit coherence restoring operations may be needed at
> synchronization points. A different operation may be needed for
> locations that were locally updated by stores and for locations that
> were remotely updated by put or accumulate operations. Without this
> constraint, the MPI library will have to track precisely which locations
> in a window were updated by a put or accumulate call. The additional
> overhead of maintaining such information is considered prohibitive. (End
> of rationale.)
>
> --snip--
>
> Sorry, I didn't think hard enough initially about the specific cases you
> mentioned and just applied my simplified rule of thumb that load/store
> conflicts with everything.
>
> I agree that load + Put/Acc and store + Get appear to be non-erroneous
> when the accesses are non-overlapping.
>
> Updated table is attached.  Does this look correct now for MPI-2 and MPI-3?
>
>    ~Jim.
>
> On 10/14/11 4:58 PM, Pavan Balaji wrote:
>>
>> I don't think believe that's correct. Both the "local update" and the
>> "put or accumulate" parts apply to the overlapping window.
>>
>> Here's the rule (which can be broken up into two rules):
>>
>> * A put or accumulate must not access a target window once a local
>> update or a put or accumulate update to another (overlapping) target
>> window have started on a location in the target window, until the update
>> becomes visible in the public copy of the window.
>>
>> * Conversely, a local update in process memory to a location in a window
>> must not start once a put or accumulate update to that target window has
>> started, until the put or accumulate update becomes visible in process
>> memory. In both cases, the restriction applies to operations even if
>> they access disjoint locations in the window.
>>
>> The second half is not relevant here because it's talking about the same
>> location, not the same window.
>>
>> The first half is not relevant here because it's talking about
>> overlapping windows.
>>
>> Even logically, the first rule only makes sense for overlapping windows.
>> It doesn't make sense for non-overlapping windows. Why would load +
>> Put/Acc be a problem?
>>
>> -- Pavan
>>
>> On 10/14/2011 04:48 PM, James Dinan wrote:
>>> I think this rule is overloaded to define semantics for both load/store
>>> and multiple windows. I believe that the parsing below with bracketed
>>> text removed is the correct interpretation for this case:
>>>
>>> A put or accumulate must not access a target window once a local update
>>> [or a put or accumulate update to another (overlapping) target window]
>>> have started on a location in the target window, until the update
>>> becomes visible in the public copy of the window. Conversely, a local
>>> update in process memory to a location in a window must not start once a
>>> put or accumulate update to that target window has started, until the
>>> put or accumulate update becomes visible in process memory. In both
>>> cases, the restriction applies to operations even if they access
>>> disjoint locations in the window.
>>>
>>> ~Jim.
>>>
>>> On 10/14/11 4:36 PM, Pavan Balaji wrote:
>>>>
>>>> That rule is for overlapping windows.
>>>>
>>>> Pavan Balaji @ iPhone
>>>> (Big fingers. Small email.)
>>>>
>>>> On Oct 14, 2011, at 4:33 PM, James Dinan<dinan at mcs.anl.gov>  wrote:
>>>>
>>>>> Rule #3 on page 365 of semantics and correctness:
>>>>>
>>>>> --snip--
>>>>>
>>>>> 3. A put or accumulate must not access a target window once a local
>>>>> update or a put or accumulate update to another (overlapping) target
>>>>> window have started on a location in the target window, until the
>>>>> update becomes visible in the public copy of the window. Conversely,
>>>>> a local update in process memory to a location in a window must not
>>>>> start once a put or accumulate update to that target window has
>>>>> started, until the put or accumulate update becomes visible in
>>>>> process memory. In both cases, the restriction applies to operations
>>>>> even if they access disjoint locations in the window.
>>>>>
>>>>> A program is erroneous if it violates these rules.
>>>>>
>>>>> --snip--
>>>>>
>>>>> ~Jim.
>>>>>
>>>>> PS- This rule is like five rules. We really should regroup once the
>>>>> ticket is accepted and see if it can be split into a few smaller,
>>>>> easier to digest rules.
>>>>>
>>>>> On 10/14/11 3:18 PM, Pavan Balaji wrote:
>>>>>>
>>>>>> Why are they incompatible in MPI-2?
>>>>>>
>>>>>> Pavan Balaji @ iPhone
>>>>>> (Big fingers. Small email.)
>>>>>>
>>>>>> On Oct 14, 2011, at 11:18 AM, James Dinan<dinan at mcs.anl.gov>  wrote:
>>>>>>
>>>>>>> In MPI-2, the are not compatible, but in MPI-3, it's ok as long as
>>>>>>> there is no overlap. I've attached an updated PDF with both MPI-2
>>>>>>> and MPI-3 tables.
>>>>>>>
>>>>>>> ~Jim.
>>>>>>>
>>>>>>> On 10/14/11 2:02 AM, Pavan Balaji wrote:
>>>>>>>>
>>>>>>>> There seem to be a few errors here: load + Put/Acc and store + Get
>>>>>>>> should be NOVL.
>>>>>>>>
>>>>>>>> -- Pavan
>>>>>>>>
>>>>>>>> On 10/10/2011 02:35 PM, James Dinan wrote:
>>>>>>>>> Hi All,
>>>>>>>>>
>>>>>>>>> We discussed creating a table that shows compatibility between
>>>>>>>>> concurrent RMA operations. A rough mockup of this table is
>>>>>>>>> attached.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Jim.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> mpi3-rma mailing list
>>>>>>>>> mpi3-rma at lists.mpi-forum.org
>>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
>>>>>>>>
>>>>>>> <rma_op_matrix.pdf>
>>>>>>> <rma_op_matrix.pptx>
>>

-- 
Pavan Balaji
http://www.mcs.anl.gov/~balaji