[Mpi3-rma] RMA proposal 1 update

Torsten Hoefler htor at illinois.edu
Tue May 25 21:16:38 CDT 2010


Rajeev,

Thank you very much for your comments! The new document is available at
the wiki. See my comments below.

> 1:34 - Need to add MPI_Get_accumulate
I also added acc_get and comp_and_swap to this list.


> 2:6-10 - Need to update this para. A draft:
> "MPI provides two initialization functions, MPI_Win_create and
> MPI_Win_allocate. MPI_Win_create allows (add enitre existing paragraph).
> MPI_Win_allocate differs from MPI_Win_create in that the user does not
> pass allocated memory; MPI_Win_allocate allocates memory and returns a
> pointer to it. 
fixed

> 4:16 - We probably need to follow the convention in MPI_Alloc_mem and
> use void *base instead of **base and provide some explanation for it.
> (See also Advice to Users for MPI_Buffer_Detach)
Right, I overlooked that one.

> 4:26 - Update for 2nd sentence: "On each process, it allocates memory of
> size size, returns a pointer to it, and returns a window object that can
> be used by the processes to perform RMA operations." Possibly delete the
> next sentence.
fixed

> 4:31 - Need pointer to the restrictions on Alloc_mem you are refering
> to.
I changed this working a bit

> 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.

> 6:14 - Add MPI_Get_accumulate
fixed (also added the two other calls)

> 6:44 - Same
gaaaa ... replaced the list with "all MPI RMA communication calls" (what
do we define it for ...)

> 13:17 - extra space before comma?
Yes, this is some problem with the macro (will go in a later version)

> 14:10 - typo "semantics"
> 14:11 - change "data but" to "data, and"
> 14:13 - initiator -> caller
fixed

> 14:16 - Are derived datatypes allowed in MPI_Get_accumulate? If so, we
> could as well allow a count argument here.
Added: "The \mpiarg{datatype} argument must be a predefined datatype."
to both functions.

> 14:46 - returns -> return
> 14:46 - move "in the result buffer" earlier: "return in the result
> buffer the content of..."
fixed

> 15:1 - MPI_NO_OP looks better
fine :)

> 15:4 - What about MPI_Accumulate?
See other mail, it's pointless, we should still straw-vote.

> 15:9 - typo "get_accumulate_get"
> 15:10 - same
> 15:15 - initiator -> caller
fixed

> 15:19 - I am wondering whether it is better to avoid an additional
> function Accumulate_get because the user can do the local accumulate
> manually at the origin after a Get_accumulate.
strawvote

> 16:3 - Same fixes as 14:46
> 16:9 - Comma before "which" (always needed)
fixed

> 17:25 - Add Get_accumulate
I put an e.g., there :)

> 27:24 - rank of target window
fixed

> 27:33 - "RMA operations issued prior to this call with rank as the
> target will have completed both at the origin and at the target when
> this call returns." (Sentence taken from MPI_Win_unlock)
yes

> 27:34 - Probably delete the next sentence because the user won't
> understand what it means without further explanation.
yes

> 27:34 - Add "This function can be called only within a lock-unlock
> epoch."
added

> 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).

> 27:48 - In any case, a better sentence: "All RMA operations issued to
> any target prior to this call will have completed both at the origin and
> at the target when this call returns. This function can be called only
> within a lock-unlock or lockall-unlockall epoch."
The last sentence doesn't make sense without having those calls :). I
believe this makes sense if we allow multiple parallel locks (which I
think we should do). Needs to be discussed.

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



More information about the mpiwg-rma mailing list