[Mpi3-rma] [EXTERNAL] Re: MPI-3 UNIFIED model clarification
jedbrown at mcs.anl.gov
Sun Aug 4 19:02:19 CDT 2013
Pavan Balaji <balaji at mcs.anl.gov> writes:
> On 08/04/2013 06:31 PM, Jed Brown wrote:
>> Pavan Balaji <balaji at mcs.anl.gov> writes:
>>> This is not an ordering issue if I'm talking about nonoverlapping
>>> memory. If P0 is doing PUTs to P1s memory, and P1 is reading some other
>>> nonoverlapping region of it's own memory, P0 and P1 need to synchronize
>>> in some way if they use the SEPARATE model (e.g., by using EXCLUSIVE
>>> locks). If they used the UNIFIED model, they can do these accesses
>>> concurrently without any synchronization.
>> At some point, P1 (or other ranks) must learn that it can now access the
>> memory that P0 was PUTing into. How would you do that?
> Jed: there is still a WIN_SYNC required when you want to use that data.
> I'm not arguing about that. My point was merely to say that there are
> cases where some accesses require additional synchronization in the
> SEPARATE model compared to UNIFIED or KIND_OF_UNIFIED (if we ever create
> such a model).
I guess I'm missing something. Why can't P1 read that other part of its
own memory in the SEPARATE model? I'm assuming that P0 executed
"""A local store accesses and updates the instance in process memory
(this includes MPI receives), but the update may affect other public
copies of the same locations. A get on a window accesses the public
copy of that window. A put or accumulate on a window accesses and
updates the public copy of that window, but the update may affect the
private copy of the same locations in process memory, and public
copies of other overlapping windows."""
Is there some other text that allows a Put to affect *non-overlapping*
parts of the private copy?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 835 bytes
Desc: not available
More information about the mpiwg-rma