[Mpi3-rma] [EXTERNAL] Re: MPI-3 UNIFIED model clarification

Jed Brown 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
something like



  """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
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-rma/attachments/20130804/d49132ac/attachment-0001.pgp>

More information about the mpiwg-rma mailing list