Skip to content
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

Closed
jdinan opened this issue Nov 4, 2015 · 8 comments
Closed

Info Assertions #11

jdinan opened this issue Nov 4, 2015 · 8 comments
Assignees
Labels
had reading Completed the formal proposal reading passed final vote Passed the final formal vote passed first vote Passed the first formal vote wg-p2p Point-to-Point Working Group

Comments

@jdinan
Copy link

jdinan commented Nov 4, 2015

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

@wesbland wesbland added this to the 2015-12 San Jose, USA milestone Nov 4, 2015
@wesbland wesbland added for review scheduled reading Reading is scheduled for the next meeting and removed for review labels Nov 4, 2015
@wesbland wesbland added the wg-hybrid Hybrid Working Group label Nov 12, 2015
@jdinan jdinan changed the title Communicator Info Assertions Info Assertions Dec 9, 2015
@dholmes-epcc-ed-ac-uk dholmes-epcc-ed-ac-uk added wg-p2p Point-to-Point Working Group and removed wg-hybrid Hybrid Working Group labels Dec 10, 2015
@rsth
Copy link

rsth commented Feb 11, 2016

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.

@jdinan
Copy link
Author

jdinan commented Feb 12, 2016

Thanks! I updated the PDF and PR with the corrected formatting for 'true' info values.

@wesbland wesbland removed the mpi-4.0 label Mar 2, 2016
This was referenced May 23, 2016
@jsquyres
Copy link
Member

@jdinan Is this to be read in Bellevue? If so, can you update the milestone? Thanks.

@hritzdorf
Copy link

There is a blank missing in "torestrict" Page 365 Line 20 of PDF draft.

@dholmes-epcc-ed-ac-uk dholmes-epcc-ed-ac-uk added had reading Completed the formal proposal reading and removed scheduled reading Reading is scheduled for the next meeting labels Jun 20, 2016
@dholmes-epcc-ed-ac-uk dholmes-epcc-ed-ac-uk added the passed first vote Passed the first formal vote label Dec 8, 2016
@dholmes-epcc-ed-ac-uk dholmes-epcc-ed-ac-uk added the passed final vote Passed the final formal vote label Mar 2, 2017
hjelmn added a commit to hjelmn/ompi that referenced this issue Jun 8, 2017
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>
@RolfRabenseifner
Copy link

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.

@RolfRabenseifner
Copy link

And yes, an advice to implementors would be a good idea.

@tonyskjellum
Copy link

tonyskjellum commented Oct 10, 2019 via email

@jdinan
Copy link
Author

jdinan commented Nov 5, 2019

The info key text is as follows:

If set to true, then the implementation may assume that point-to-point communications on the given communicator do not rely on the non-overtaking rule speci ed in Section 3.5.

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
had reading Completed the formal proposal reading passed final vote Passed the final formal vote passed first vote Passed the first formal vote wg-p2p Point-to-Point Working Group
Projects
None yet
Development

No branches or pull requests

8 participants