[Mpi3-rma] RMA op compatibility matrix

[James Dinan]

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: 36407 bytes
Desc: not available
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-rma/attachments/20111014/6bc7e422/attachment-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rma_op_matrix.pptx
Type: application/vnd.openxmlformats-officedocument.presentationml.presentation
Size: 84223 bytes
Desc: not available
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-rma/attachments/20111014/6bc7e422/attachment-0001.pptx>