[Mpi3-rma] Unified model discussion

Underwood, Keith D keith.d.underwood at intel.com
Sat Apr 2 13:19:43 CDT 2011


Does Win_sync currently have to be called during an epoch on the local processor?  Would we want to relax that restriction?

Keith

> -----Original Message-----
> From: mpi3-rma-bounces at lists.mpi-forum.org [mailto:mpi3-rma-
> bounces at lists.mpi-forum.org] On Behalf Of Pavan Balaji
> Sent: Saturday, April 02, 2011 11:37 AM
> To: MPI 3.0 Remote Memory Access working group
> Subject: Re: [Mpi3-rma] Unified model discussion
> 
> 
> In the case of SEPARATE, Win_sync will be required to do two things:
> (1)
> order load/stores, and (2) synchronize public/private windows.
> 
> We can as well use Win_sync for unified too, and just get it to do the
> first part.
> 
>   -- Pavan
> 
> On 04/02/2011 12:35 PM, William Gropp wrote:
> > Would that call also complete/order local memory operations (e.g., we
> > could use the same routine)?
> >
> > Bill
> >
> > On Apr 2, 2011, at 11:50 AM, Underwood, Keith D wrote:
> >
> >> That is an important point.  What if we allow unified to work for
> >> this use case without additional calls, but add a call to force
> >> synchronization when the local and remote accesses would conflict?
> >>
> >> Keith
> >>
> >>> -----Original Message-----
> >>> From: mpi3-rma-bounces at lists.mpi-forum.org [mailto:mpi3-rma-
> >>> bounces at lists.mpi-forum.org] On Behalf Of Pavan Balaji
> >>> Sent: Thursday, March 31, 2011 3:52 PM
> >>> To: mpi3-rma at lists.mpi-forum.org
> >>> Subject: [Mpi3-rma] Unified model discussion
> >>>
> >>>
> >>> When we were having the discussion on the unified model during the
> >>> last
> >>> working group meeting, I forgot to point out one important use
> case:
> >>>
> >>> Process 0
> >>> ----------
> >>> Win_lock(shared, P0)
> >>> load(A)
> >>> store(B)
> >>> Win_unlock
> >>>
> >>> Process 1
> >>> ---------
> >>> Win_lock(shared, P0)
> >>> Put(C)
> >>> Get(D)
> >>> Win_unlock
> >>>
> >>> That is, two processes are reading/writing to different parts of
> the
> >>> window. This is an important model and can only be supported in
> >>> unified,
> >>> not separate (because of potential cache-line false sharing).
> >>>
> >>> So, basically, no we cannot remove the unified model in spite of
> all
> >>> its
> >>> nonsense with load/store ordering.
> >>>
> >>>   -- Pavan
> >>>
> >>> --
> >>> Pavan Balaji
> >>> http://www.mcs.anl.gov/~balaji
> >>> _______________________________________________
> >>> mpi3-rma mailing list
> >>> mpi3-rma at lists.mpi-forum.org
> >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
> >>
> >> _______________________________________________
> >> mpi3-rma mailing list
> >> mpi3-rma at lists.mpi-forum.org
> >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
> >
> > William Gropp
> > Deputy Director for Research
> > Institute for Advanced Computing Applications and Technologies
> > Paul and Cynthia Saylor Professor of Computer Science
> > University of Illinois Urbana-Champaign
> >
> >
> >
> >
> > _______________________________________________
> > mpi3-rma mailing list
> > mpi3-rma at lists.mpi-forum.org
> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
> 
> --
> Pavan Balaji
> http://www.mcs.anl.gov/~balaji
> _______________________________________________
> mpi3-rma mailing list
> mpi3-rma at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma




More information about the mpiwg-rma mailing list