[Mpi3-rma] RMA op compatibility matrix

[James Dinan]

Ahh, right.  Thanks for your help.  Updated tables are attached.

  ~Jim.

On 10/14/11 5:42 PM, Pavan Balaji wrote:
> 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>
>>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rma_op_matrix.pdf
Type: application/pdf
Size: 40160 bytes
Desc: not available
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-rma/attachments/20111014/c2e8e117/attachment-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rma_op_matrix.pptx
Type: application/vnd.openxmlformats-officedocument.presentationml.presentation
Size: 86483 bytes
Desc: not available
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-rma/attachments/20111014/c2e8e117/attachment-0001.pptx>