[Mpi3-rma] RMA proposal 1 update

Underwood, Keith D keith.d.underwood at intel.com
Tue May 25 23:04:41 CDT 2010


Lockall/unlockall was definitely on the list at the last meeting.  There wasn't consensus on many things, but there was on that one ;-)

Keith

> -----Original Message-----
> From: mpi3-rma-bounces at lists.mpi-forum.org [mailto:mpi3-rma-
> bounces at lists.mpi-forum.org] On Behalf Of Torsten Hoefler
> Sent: Tuesday, May 25, 2010 9:57 PM
> To: Rajeev Thakur
> Cc: bwbarre at Sandia.gov; rbbrigh at Sandia.gov; mpi3-rma at lists.mpi-
> forum.org
> Subject: Re: [Mpi3-rma] RMA proposal 1 update
> 
> On Tue, May 25, 2010 at 09:38:04PM -0500, Rajeev Thakur wrote:
> > > > 5:12-14 - Update: "If the window was created with MPI_Win_create,
> > the
> > > > user is responsible for freeing the window memory after
> MPI_Win_free
> > > > returns. If the window was created with MPI_Win_allocate,
> > MPI_Win_free
> > > > will free the window memory that was allocated in
> MPI_Win_allocate."
> > > I think we should not prescribe what the user has to do. He might
> as
> > > well choose to never free the memory and this is outside the scope
> of
> > > the MPI standard. I don't see a problem with the current phrasing.
> >
> > I wanted to make it clear who is freer rather than saying "can be
> > freed", "will be freed" (by whom?). How about this:
> >
> > "If the window was created with MPI_Win_create, the user may free the
> > window memory after MPI_Win_free returns. If the window was created
> with
> > MPI_Win_allocate, MPI_Win_free will free the window memory that was
> > allocated in MPI_Win_allocate."
> I don't like the term "user" but I took the second part (which doesn't
> sound great but it's clear).
> 
> > Or you can say the user may choose to, if he so wishes, free the
> window
> > memory... :-)
> Sure. MPI seems to use passive voice more often than active. Check now
> :).
> 
> > > > 27:38 - Flushall is not useful unless there is a corresponding
> > > > lockall/unlockall.
> > > I believe this needs to be discussed (I don't think this statement
> is
> > > true).
> >
> > MPI_Win_lock allows RMA to a single target rank. How can you do a
> > flushall to multiple ranks? Nesting of multiple MPI_Win_lock calls is
> > not allowed in the current version of your proposal, is it?
> >
> > I thought you were going to add Lockall/Unlockall, but just forgot to
> > :-).
> That would be easy, however, I didn't have it on my list of things to
> add. You're right that it's currently not allowed, however, I meant
> that
> there is more than one way to make use of it (without (un)lockall :).
> 
> We shall discuss at the next telecon. I have no objections to adding
> it.
> 
> All the Best,
>   Torsten
> 
> --
>  bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ -----
> Torsten Hoefler         | Research Associate
> Blue Waters Directorate | University of Illinois
> 1205 W Clark Street     | Urbana, IL, 61801
> NCSA Building           | +01 (217) 244-7736
> _______________________________________________
> 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