[Mpi3-rma] RMA proposal 1 update

Rajeev Thakur thakur at mcs.anl.gov
Mon May 24 17:50:41 CDT 2010


Torsten,
        Thanks for the updated proposal. Below are some detailed
comments.

Rajeev


1:34 - Need to add MPI_Get_accumulate

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

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.

4:31 - Need pointer to the restrictions on Alloc_mem you are refering
to.

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

6:14 - Add MPI_Get_accumulate

6:44 - Same

13:17 - extra space before comma?

14:10 - typo "semantics"

14:11 - change "data but" to "data, and"

14:13 - initiator -> caller

14:16 - Are derived datatypes allowed in MPI_Get_accumulate? If so, we
could as well allow a count argument here.

14:46 - returns -> return

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

15:1 - MPI_NO_OP looks better

15:4 - What about MPI_Accumulate?

15:9 - typo "get_accumulate_get"

15:10 - same

15:15 - initiator -> caller

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.

16:3 - Same fixes as 14:46

16:9 - Comma before "which" (always needed)

17:25 - Add Get_accumulate

27:24 - rank of target window

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)

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

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

27:38 - Flushall is not useful unless there is a corresponding
lockall/unlockall.

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


> -----Original Message-----
> From: Torsten Hoefler [mailto:htor at illinois.edu] 
> Sent: Sunday, May 16, 2010 12:48 AM
> To: mpi3-rma at lists.mpi-forum.org
> Cc: wgropp at illinois.edu; balaji at mcs.anl.gov; 
> thakur at mcs.anl.gov; bwbarre at Sandia.gov; rbbrigh at Sandia.gov
> Subject: RMA proposal 1 update
> 
> Hello all,
> 
> After the discussions at the last Forum I updated the group's first
> proposal. 
> 
> The proposal (one-side-2.pdf) is attached to the wiki page
> https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/RmaWikiPage
> 
> The changes with regards to the last version are:
> 
> 1) added MPI_NOOP to MPI_Get_accumulate and MPI_Accumulate_get
> 
> 2) (re)added MPI_Win_flush and MPI_Win_flush_all to passive 
> target mode
> 
> Some remarks:
> 
> 1) We didn't straw-vote on MPI_Accumulate_get, so this function might
>    go. The removal would be very clean.
> 
> 2) Should we allow MPI_NOOP in MPI_Accumulate (this does not 
> make sense
>    and is incorrect in my current proposal)
> 
> 3) Should we allow MPI_REPLACE in 
> MPI_Get_accumulate/MPI_Accumulate_get?
>    (this would make sense and is allowed in the current 
> proposal but we
>    didn't talk about it in the group)
> 
> 
> 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