-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Info Assertions #11
Comments
For the four new asserts on pg 249, can we change "If set to true" to "If set to \infoval{true}" so that true appears in the right font. See, for example, the values for the collective_buffering key on pg 502. |
Thanks! I updated the PDF and PR with the corrected formatting for 'true' info values. |
@jdinan Is this to be read in Bellevue? If so, can you update the milestone? Thanks. |
There is a blank missing in "torestrict" Page 365 Line 20 of PDF draft. |
This commit adds code to allow support for the info assertions added by mpi-forum/mpi-issues#11. The assertions added are: mpi_assert_no_any_tag, mpi_assert_no_any_source, mpi_assert_exact_length, and mpi_assert_allow_overtaking. This commit also adds support for the mpi_assert_no_any_source and mpi_assert_allow_overtaking info keys to the ob1 pml. Signed-off-by: Nathan Hjelm <hjelmn@lanl.gov>
In general, when implementing blocking and non-blocking collective communication internally with MPI point-to-point then the overtaking must be switched off for such messages, which may be not a problem if the communicator is duplicated without duplicationg this info about overtaking is allowed. |
And yes, an advice to implementors would be a good idea. |
Sure but the standard just has to say that the assertion only applies to point to point ; it is ok as advice to implementers to remind them
Anthony Skjellum, PhD
205-807-4968
… On Oct 10, 2019, at 12:27 PM, Rolf Rabenseifner ***@***.***> wrote:
In general, when implementing blocking and non-blocking collective communication internally with MPI point-to-point then the overtaking must be switched off for such messages, which may be not a problem if the communicator is duplicated without duplicationg this info about overtaking is allowed.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
The info key text is as follows:
If there is an advice needed, perhaps it is advice to implementors to be careful that support for this info key doesn't break their collectives? |
Summary
This ticket relaxes the restriction that info keys cannot change semantics. It allows info keys to be used to provide application behavior hints, which an implementation can use to restrict the set of functionality or semantics supported, e.g. on a particular communicator, to optimize performance for the given usage model.
The proposal has been split into three parts:
Proposed Changes
Related Tickets
Proposal Drafts
The text was updated successfully, but these errors were encountered: