[mpiwg-rma] FW: [Mpi3-rma] [EXTERNAL] Re: MPI-3 UNIFIED model updates
Underwood, Keith D
keith.d.underwood at intel.com
Tue Aug 27 07:15:11 CDT 2013
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
> 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
> 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
More information about the mpiwg-rma