Btw, even in your interpretation what I said still holds true: load + Put/Acc and store + Get should be NOVL. The rule is says that put/acc + store don't mix. And put/acc + put/acc for overlapping windows don't mix. -- Pavan On 10/14/2011 04: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<[email protected]> 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<[email protected]> 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 [email protected] 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