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<[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