[mpiwg-rma] FW: [Mpi3-rma] [EXTERNAL] Re: MPI-3 UNIFIED model updates

[Underwood, Keith D]

Sorry, let me try to put it in slightly more clear language. The email thread I replied to said (with general agreement):

>> I prefer option #1 -- that a window synchronization (e.g. Win_sync) 
>> can be used to order load/store operations with respect to actions 
>> performed by other processes in the target's window.  If no ordering 
>> is enforced, the MPI standard does not define what is seen by load 
>> operations at the target process.  As a rationale, the local process' 
>> view of the window may not be consistent with the window because of 
>> performance optimizations or the consistency model of the underlying 
>> architecture.  This would allow e.g. SHMEM implementations to still 
>> use MPI-3 RMA, but they would have to rely on a behavior that is 
>> defined by the architecture/implementation, as they currently do.

My statement:  this seems to be what SHMEM does - except they don't provide the equivalent of Win_sync.  If we are going to hack on the text, I would prefer that we be *very* careful in our wording.  Specifically, we need to make it very clear that the SHMEM approach is *legal*, but the burden is on the user to do potentially implementation specific things to make it work right.

> -----Original Message-----
> From: Pavan Balaji [mailto:balaji at mcs.anl.gov]
> Sent: Monday, August 26, 2013 11:38 PM
> To: mpiwg-rma at lists.mpi-forum.org
> Cc: Underwood, Keith D
> Subject: Re: [mpiwg-rma] FW: [Mpi3-rma] [EXTERNAL] Re: MPI-3 UNIFIED
> model updates
> 
> Keith,
> 
> On 08/26/2013 08:00 PM, Underwood, Keith D wrote:
> >> Well, after asking somebody what happens with SHMEM on such
> >> architectures, I believe they basically tell the user "program this
> >> like you would a multithreaded program - all such rules apply".  I
> >> don't see why we don't take that approach.  It seems to me to be the
> >> closest to the objective of unified...
> 
> I think your comment is really talking about the previous thread of emails on
> this topic.  Let me try to clarify this here, but that was not the intent of this
> email thread.
> 
> There are really three memory models: SEPARATE,
> UNIFIED_REQUIRING_WIN_SYNC, and
> UNIFIED_NOT_REQUIRING_WIN_SYNC.
> 
> SEPARATE is what we already have in the standard.
> UNIFIED_REQUIRING_WIN_SYNC is where the target has to call WIN_SYNC
> to synchronize the public/private windows for overlapping data, but
> nonoverlapping data can be accessed without synchronization.
> UNIFIED_NOT_REQUIRING_WIN_SYNC is where the target data is always
> synchronized between the public/private windows.
> 
> Some folks on the WG thought that "UNIFIED" in the MPI-3 standard meant
> UNIFIED_REQUIRING_WIN_SYNC, while others thought it meant
> UNIFIED_NOT_REQUIRING_WIN_SYNC.  So the chapter is in an inconsistent
> state right now.  Most of the previous email thread was to come to a
> consensus on these different memory models and we agreed that these
> three exist, irrespective of whether we want to support them in the MPI
> standard or not.
> 
> In this email thread, we are trying to pick one of two options:
> 
> 1. Change the wording in the MPI standard so "UNIFIED" means
> UNIFIED_REQUIRING_WIN_SYNC.  This seems to be the option that got most
> votes so far.  In fact, folks feel that this can be done as an errata item, though
> whether the Forum will accept that as an errata remains to be seen.  It is
> important to note that this option would mean that we will not have a way to
> represent the UNIFIED_NOT_REQUIRING_WIN_SYNC model.
> 
> 2. Change the wording in the MPI standard so "UNIFIED" means
> UNIFIED_NOT_REQUIRING_WIN_SYNC, but add another memory model for
> UNIFIED_REQUIRING_WIN_SYNC.  This option only got my vote so far :-).
> 
>   -- Pavan
> 
> --
> Pavan Balaji
> http://www.mcs.anl.gov/~balaji