Updated RMA chapter #270

mpiforumbot · 2016-07-24T15:46:46Z

Originally by gropp on 2011-03-14 08:32:23 -0500

The RMA working group has extensively revised the RMA chapter to add, in a way consistent with the MPI-2 RMA and MPI in general, new RMA support. These include ways to attach memory to an MPI_Win, perform read-modify-write operations, and use requests on RMA operations. In addition, in response to many requests, many operations previously defined as erroneous now have undefined (but not erroneous) behavior, which is similar to other one-sided programming models. As the chapter has been extensively revised, this ticket is for the entire chapter, and has been accepted by the RMA working group (chapter committee).

Minor edits to this chapter are in #275.

"Ticket 0" changes are expected to be submitted separately, though some updates have been made while updating the text of the chapter.

In addition to the new one sided chapter, the following changes are added to Annex A:

Error classes:

MPI_ERR_RMA_RANGE
MPI_ERR_RMA_ATTACH

Collective operations:

MPI_NO_OP

Attributes

MPI_WIN_CREATE_FLAVOR
MPI_WIN_MODEL

Add a new table, "MPI Window Create Flavors":

C type const int (or unnamed enum)
Fortran type INTEGER
MPI_WIN_FLAVOR_CREATE
MPI_WIN_FLAVOR_ALLOCATE
MPI_WIN_FLAVOR_DYNAMIC

Add a new table, "MPI Window Models":

C type const int (or unnamed enum)
Fortran type INTEGER
MPI_WIN_SEPARATE
MPI_WIN_UNIFIED

Note no C++ values unless C++ is undeprecated.

The change log entry is:

Substantial revision of the entire One-sided chapter, with new routines for window creation, additional synchronization methods in passive target, new one-sided communication routines, a new memory model, and other changes.

The text was updated successfully, but these errors were encountered:

mpiforumbot · 2016-07-24T15:46:50Z

Originally by htor on 2011-10-26 11:30:21 -0500

Brian's implementation is available at the following SVN repository:

http://svn.open-mpi.org/svn/ompi/tmp-public/mpi3-onesided/

See his email to the mpi-forum mailinglist from Wed, 12 Oct 2011 for details!

Torsten

mpiforumbot · 2016-07-24T15:46:50Z

Originally by moody20 on 2011-10-27 19:39:12 -0500

A bunch of ticket 0 changes ... (based on one-side-2.2.pdf)

There are several sentences where we use the term "memory registration", but we don't define what that means. The text only talks about "attaching memory", so we should use this term instead, especially since "memory registration" is commonly used in modern machines to mean something similar but different.

p7, 40
"Memory registration may require" --> "Memory attachment may require"

p7, 42
"Memory registration may fail" --> "Memory attachment may fail"

p7, 44
"that memory registration at the target" --> "that memory attachment at the target"

p8, 2
"A high-quality implementation will attempt to make as much memory available for registration as possible." --> "A high-quality implementation will attempt to make as much memory available for attachment as possible."

p8, 5
"Memory registration is a" --> "Memory attachment is a"

p9, 29-30
missing commas in list after get_attr calls for size, disp_unit, and create_kind (before the "and")

p9, 39
missing comma in list after get_attr call for disp_unit

p9, 42
missing comma after disp_unit and create_kind (before "and")

p13, 18
Add MPI_WIN_ALLOCATE after MPI_MEM_ALLOC, since MPI_WIN_ALLOCATE also allocates "special" memory?

p22, 41-42
Drop ", or can be of type MPI_AINT or MPI_OFFSET", since these types are already included in the "Fortran integer" group.

p23, 6-7
Regarding status, we should either say that all fields are undefined (except for the error) or we should specify all values, e.g., what about values returned for MPI_GET_COUNT, MPI_GET_ELEMENTS, or MPI_TEST_CANCELLED? Replace "The values of the MPI_SOURCE and MPI_TAG fields are undefined." with "All other fields in status are undefined."

Question: Would it be useful to set fields for count and get elements?

p45, 38
Drop "in MPI-3" from statement. It's not needed since it's meant to apply to the current MPI standard and presumably all later versions, while leaving it there is bound to cause a problem when MPI-4 and later are released.

p52, 36
Change "in MPI-3" to "in MPI-3 and later" (similar argument as above).

p60, 27
We should show create call, since MPI_WIN_DYNAMIC in particular cannot be used (because displacements != 1). As written, this code does not work for MPI_WIN_DYNAMIC windows.

mpiforumbot · 2016-07-24T15:46:51Z

Originally by htor on 2011-11-21 17:37:37 -0600

Attachment added: one-side-2.pdf (585.9 KiB)
Includes markup to show changes from MPI-2.2

mpiforumbot · 2016-07-24T15:46:51Z

Originally by htor on 2011-11-21 17:38:55 -0600

Hi Adam,
Thanks for the review comments below!

A bunch of ticket 0 changes ... (based on one-side-2.2.pdf)
good ;-)

There are several sentences where we use the term "memory registration", but
we don't define what that means. The text only talks about "attaching memory",
so we should use this term instead, especially since "memory registration" is
commonly used in modern machines to mean something similar but different.
Good point -- I fixed five of those.

p7, 40 "Memory registration may require" --> "Memory attachment may require"

p7, 42 "Memory registration may fail" --> "Memory attachment may fail"

p7, 44 "that memory registration at the target" --> "that memory attachment at the target"

p8, 2 "A high-quality implementation will attempt to make as much memory available for registration as possible." --> "A high-quality implementation will attempt to make as much memory available for attachment as possible."

p8, 5 "Memory registration is a" --> "Memory attachment is a"
All done -- slightly different wording ("Memory attachment" sounds a bit
weird, changed it to "Mttaching memory to a window" where possible)

p9, 29-30 missing commas in list after get_attr calls for size,
disp_unit, and create_kind (before the "and")
done

p9, 39 missing comma in list after get_attr call for disp_unit
done

p9, 42 missing comma after disp_unit and create_kind (before "and")
done

p13, 18 Add MPI_WIN_ALLOCATE after MPI_MEM_ALLOC, since
MPI_WIN_ALLOCATE also allocates "special" memory?
good catch -- done

p22, 41-42 Drop ", or can be of type MPI_AINT or MPI_OFFSET", since
these types are already included in the "Fortran integer" group.
done

p23, 6-7 Regarding status, we should either say that all fields are
undefined (except for the error) or we should specify all values,
e.g., what about values returned for MPI_GET_COUNT, MPI_GET_ELEMENTS,
or MPI_TEST_CANCELLED? Replace "The values of the MPI_SOURCE and
MPI_TAG fields are undefined." with "All other fields in status are
undefined."
uff, this is a more complex issue -- we'll discuss this at the next
telecon (the opaque fields in status objects are never called "fields").

Question: Would it be useful to set fields for count and get elements?
-> next telecon :)

p45, 38 Drop "in MPI-3" from statement. It's not needed since it's
meant to apply to the current MPI standard and presumably all later
versions, while leaving it there is bound to cause a problem when
MPI-4 and later are released.
This is intentional to capture the history and explicitly make users
aware that this was different until MPI-3.

p52, 36 Change "in MPI-3" to "in MPI-3 and later" (similar argument as
above).
I'll stick to MPI-3 here (it's for all MPI-3.x -- when MPI-4 comes, we
may want to change that statement (cf. other statements about MPI-2 in
the MPI-2.2 standard).

p60, 27 We should show create call, since MPI_WIN_DYNAMIC in
particular cannot be used (because displacements != 1). As written,
this code does not work for MPI_WIN_DYNAMIC windows.
Ok, added MPI_Win_allocate. Please double-check.

mpiforumbot · 2016-07-24T15:46:52Z

Originally by jsquyres on 2012-01-10 11:21:18 -0600

Torsten tells me that this implementation is complete.

mpiforumbot · 2016-07-24T15:46:53Z

Originally by htor on 2012-05-29 01:41:48 -0500

Committed a long time ago,

Torsten

mpiforumbot · 2016-07-24T15:46:53Z

Originally by RolfRabenseifner on 2012-06-29 12:53:40 -0500

appLang committed (SVN 1210)

mpiforumbot · 2016-07-24T15:51:54Z

Originally by jsquyres on 2012-07-03 09:17:04 -0500

Reviewed applang commit.

mpiforumbot · 2016-07-24T15:51:55Z

Originally by RolfRabenseifner on 2012-07-10 09:08:44 -0500

Comment https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/284#comment:24
does also apply for MPI_WIN_ALLOCATE.

It is fixed together with the #284 and marked with 229.5.

mpiforumbot · 2016-07-24T15:51:55Z

Originally by hubertritzdorf on 2012-07-15 09:00:36 -0500

Documents mpi-report-r1244.pdf) (and mpi-report-r1270.pdf
There is an additional paragraph break directly after Example 11.22 (page 486, Line 18 in mpi-report-r1244.pdf) which is not contained in the ticket or other examples.
There is an additional advice to users (Page 461 Line 47 - Page 462 Line 2) which seems not to be contained in the ticket (relative to one-side-2.pdf).

mpiforumbot · 2016-07-24T15:51:55Z

Originally by htor on 2012-07-15 16:38:52 -0500

Replying to hubertritzdorf:

Documents mpi-report-r1244.pdf) (and mpi-report-r1270.pdf
There is an additional paragraph break directly after Example 11.22 (page 486, Line 18 in mpi-report-r1244.pdf) which is not contained in the ticket or other examples.
Can you elaborate on this? I don't see the problem.

There is an additional advice to users (Page 461 Line 47 - Page 462 Line 2) which seems not to be contained in the ticket (relative to one-side-2.pdf).
Yes, this was introduced as a ticket 0 change by the working group. It's not mandatory and rather uncontroversial.

Thanks & Best,
Torsten

mpiforumbot · 2016-07-24T15:51:56Z

Originally by hubertritzdorf on 2012-07-16 04:29:28 -0500

The additional paragraph break is inconsistent to the other examples in Section 11.8 and
a small change to the original ticket. Since many small changes in actual tickets addresses such inconsistencies, I simply wanted to point to this difference.

mpiforumbot · 2016-07-24T15:51:56Z

Originally by htor on 2012-07-16 09:23:16 -0500

Replying to hubertritzdorf:

The additional paragraph break is inconsistent to the other examples in Section 11.8 and
a small change to the original ticket. Since many small changes in actual tickets addresses such inconsistencies, I simply wanted to point to this difference.
Good point! I just found it ;-). Fixed in r1301:

http://www.unixer.de/sec/mpi-report-r1301.pdf

Torsten

mpiforumbot · 2016-07-24T15:51:57Z

Originally by potluri on 2012-07-16 10:58:32 -0500

Review based off mpi-report-r1300.pdf. Below are a few comments. Thanks.

Page 428: Line 8 -
Page 429: Line 29 -
"allocates memory of at least size size bytes" --> allocates memory of at least size bytes

Page 435: Line 13 -
"it has the same effect as if all attached memory was detached by a call to MPI_WIN_DETACH" --> it has the same effect as if all attached memory was detached by calls to MPI_WIN_DETACH

Page 437: Line 15

"MPI_COMPARE_AND_SWAP performs a remote compare and swap operation" --> MPI_COMPARE_AND_SWAP performs an remote atomic compare and swap operation

Page 449

There is no mention of atomicity in the description after MPI_COMPARE_AND_SWAP. However, atomic compare and swap is mentioned in the text before it. I hope this will suffice but thought of bringing it up

Page 475 Lines 3-5

"If fence or post-start-complete-wait synchronization is used, updates to a public window copy can be delayed in both memory models until the window owner executes a synchronization call."

this contradicts with the text below from Page 474 Lines 30-31

"In the RMA unied memory model, an update of a location in a private window in process memory becomes visible without additional RMA calls"

Sorry if I am taking it out of context

Page 475 Line 20

"multiple MPI_PUT operation" --> multiple MPI_PUT operations

mpiforumbot · 2016-07-24T15:51:57Z

Originally by potluri on 2012-07-16 13:03:16 -0500

One more minor comment based on mpi-report-r1300.pdf

Page 452: Line 31
Description for origin_datatype parameter in MPI_RACCUMUATE
datatype of each buffer entry --> datatype of each entry in origin buffer
(to be uniform with that for earlier operations)
Similarly, for target_datatype and for origin_datatype, result_datatype and target_datatype in MPI_RGET_ACCUMULATE

mpiforumbot · 2016-07-24T15:51:58Z

Originally by htor on 2012-07-17 11:12:31 -0500

Replying to potluri:

Review based off mpi-report-r1300.pdf. Below are a few comments. Thanks.
Thank you!

Page 428: Line 8 -
Page 429: Line 29 -
"allocates memory of at least size size bytes" --> allocates memory of at least size bytes
done

Page 435: Line 13 -
"it has the same effect as if all attached memory was detached by a call to MPI_WIN_DETACH" --> it has the same effect as if all attached memory was detached by calls to MPI_WIN_DETACH
done

Page 437: Line 15

"MPI_COMPARE_AND_SWAP performs a remote compare and swap operation" --> MPI_COMPARE_AND_SWAP performs an remote atomic compare and swap operation
done

Page 449

There is no mention of atomicity in the description after MPI_COMPARE_AND_SWAP. However, atomic compare and swap is mentioned in the text before it. I hope this will suffice but thought of bringing it up
I think this is fine, since it's clearly defined.

Page 475 Lines 3-5

"If fence or post-start-complete-wait synchronization is used, updates to a public window copy can be delayed in both memory models until the window owner executes a synchronization call."

this contradicts with the text below from Page 474 Lines 30-31
I think we discussed this yesterday but we may revisit it in the group.

"In the RMA unied memory model, an update of a location in a private window in process memory becomes visible without additional RMA calls"

Sorry if I am taking it out of context
no worries

Page 475 Line 20

"multiple MPI_PUT operation" --> multiple MPI_PUT operations
done

Comment 21 is also applied.

Please check http://www.unixer.de/sec/mpi-report.pdf .

Thanks,
Torsten

mpiforumbot · 2016-07-24T15:51:58Z

Originally by htor on 2012-07-17 12:38:02 -0500

The issue with MPI_Win_flush is fixed now after discussion at the Forum. Please check:

http://www.unixer.de/sec/mpi-report.pdf

Torsten

mpiforumbot · 2016-07-24T15:51:58Z

Originally by jdinan on 2012-07-17 18:04:08 -0500

Reviewed r1300, minus the examples. Changes published to mailing list in pdf markup and have been applied.

mpiforumbot · 2016-07-24T15:51:59Z

Originally by goodell on 2012-07-17 21:33:13 -0500

MPI_Win_flush and friends review: OK as of Torsten's PDF.

mpiforumbot · 2016-07-24T15:51:59Z

Originally by hubertritzdorf on 2012-07-18 09:17:44 -0500

MPI_Win_flush and related function changes review: OK

mpiforumbot · 2016-07-24T15:52:00Z

Originally by jsquyres on 2012-07-18 09:58:24 -0500

Appears to be fully committed. Moving to "Waiting for PDF reviews".

mpiforumbot · 2016-07-24T15:52:01Z

Originally by RolfRabenseifner on 2013-01-07 11:22:33 -0600

Since Sep. 21, 2012, this ticket is included in MPI-3.0 and the pdf is checked according to https://svn.mpi-forum.org/svn/mpi-forum-docs/trunk/meetings/2012-07-jul/mpi3-tickets.xlsx

Therefore, by proxy / on behalf of the ticket owner, I close it with priority "Ticket complete", resolution "Text committed".

mpiforumbot self-assigned this Jul 24, 2016

mpiforumbot added this to the 2012/01/09 California, USA milestone Jul 24, 2016

mpiforumbot added New routine(s) Ticket complete MPI 3.0 Text committed labels Jul 24, 2016

mpiforumbot added Passed and removed Ticket complete labels Jul 24, 2016

mpiforumbot removed the Passed label Jul 24, 2016

mpiforumbot added Waiting for PDF reviews Ticket complete and removed Waiting for PDF reviews labels Jul 24, 2016

mpiforumbot closed this as completed Jul 24, 2016

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Updated RMA chapter #270

Updated RMA chapter #270

mpiforumbot commented Jul 24, 2016 •

edited

Loading

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

Updated RMA chapter #270

Updated RMA chapter #270

Comments

mpiforumbot commented Jul 24, 2016 • edited Loading

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016 •

edited

Loading