[mpiwg-sessions] Final comments on last tweaks for MPI Sessions

schulzm at in.tum.de schulzm at in.tum.de
Tue Oct 1 14:15:05 CDT 2019

Hi Dan, Howard, all,

I finally had a chance to look over the latest changes and generally this is looking good to me, but I have a few more comments:

First a detail that I came across when trying to build
- dynamic-2.tex, line 964: Misses an \ before the _ in MPI_Comm to build

Regarding PSETs:
	I think this works
	This may raise concerns (I would have to agree), as this is the old style of returning strings and we just decided to fix the info string text with a new way to return text. Also, if we do want to make names mutable at some point, then this would not be thread safe. Using the INOUT option for length argument would be better.
	I think we need a similar text here as in the MP_T chapter:

After a successful call to MPI_T_CVAR_GET_INFO for a particular variable, subsequent calls to this routine that query information about the same variable must return the same information. An MPI implementation is not allowed to alter any of the returned values.

	Only this ensures that process sets are not “replaced” by the implementation and a user can cache data.

Set versioning:

One other concern that I have, but I am not sure how to properly address it, so I want to just throw it out: I think we will have to have some option for versioning sets - only this will prevent a blow up in sets that we have to remember once we go to dynamic sets. In this case, an MPI implementation would only have to report data for the latest set and hence could replace sets. I know we don’t want to deal with this now and we are also not sure, if this is the right answer, but it would be nice to add something that allow us to do this later. Adding a real version argument is probably too vague at the moment, but what about adding a - currently unused - info object in the PSET query function? Another option would be to reserve a character in the URI that right now can’t be used, but later can be used as a delimiter. 

In general, shouldn’t we specify the URI format more? In this case, the “:” would already be such a delimiter.

Other comments:
- What is the default thread level when no info object is specified?
- MPI_Session_finalize, "it must locally complete all MPI operations that it initiated” needs to be restricted to all communication associated with the session, other sessions should be unaffected
- 10.3.2: A process set caches key/value tuples which -> that

One other thing that I noticed:
- Section 10.10.2 - I think this text needs to be updated as well to include the use of Sessions

If you want to go through this tomorrow on the virtual meeting, I would be available.



Prof. Dr. Martin Schulz, Chair of Computer Architecture and Parallel Systems
Department of Informatics, TU-Munich, Boltzmannstraße 3, D-85748 Garching
Member of the Board of Directors at the Leibniz Supercomputing Centre (LRZ)
Email: schulzm at in.tum.de

> On 30. Sep 2019, at 14:00, HOLMES Daniel <d.holmes at epcc.ed.ac.uk> wrote:
> Hi Martin,
> Do you have comments on the tweaked wording about psets for the sessions proposal?
> The new text, incorporating feedback from the virtual meeting, can be found here:
> https://github.com/mpiwg-sessions/mpi-standard/pull/37 <https://github.com/mpiwg-sessions/mpi-standard/pull/37>
> (You should already have access to this because you are a member of that Github organisation.)
> We have no other topics for our WG telecon this afternoon. In the absence of additional comments, we will cancel today’s meeting and give up our priority slot for this week’s virtual meeting.
> Cheers,
> Dan.
>> Dr Daniel Holmes PhD
> Architect (HPC Research)
> d.holmes at epcc.ed.ac.uk <mailto:d.holmes at epcc.ed.ac.uk>
> Phone: +44 (0) 131 651 3465
> Mobile: +44 (0) 7940 524 088
> Address: Room 2.09, Bayes Centre, 47 Potterrow, Central Area, Edinburgh, EH8 9BT
>> The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-sessions/attachments/20191001/fba18892/attachment.html>

More information about the mpiwg-sessions mailing list