[mpiwg-sessions] MPI sessions and MPI T

[Pritchard Jr., Howard]

HI Tony,

Responses interweaved below:

--
Howard Pritchard
HPC-DES
Los Alamos National Laboratory


From: <mpiwg-sessions-bounces at lists.mpi-forum.org<mailto:mpiwg-sessions-bounces at lists.mpi-forum.org>> on behalf of Dan Holmes <dholmes at epcc.ed.ac.uk<mailto:dholmes at epcc.ed.ac.uk>>
Reply-To: MPI Sessions working group <mpiwg-sessions at lists.mpi-forum.org<mailto:mpiwg-sessions at lists.mpi-forum.org>>
Date: Friday, January 27, 2017 at 7:07 AM
To: MPI Sessions working group <mpiwg-sessions at lists.mpi-forum.org<mailto:mpiwg-sessions at lists.mpi-forum.org>>
Subject: Re: [mpiwg-sessions] MPI sessions and MPI T

Hi Howard,

Thanks - that looks like a manageably short list. Here’s my initial thoughts.

1) terminology: I’m torn on this - it wouldn’t be the first naming clash in MPI (e.g. MPI_WAIT vs MPI_WIN_WAIT) but that’s no excuse to add another. The name MPI Sessions has achieved some useful brand awareness, which we shouldn’t give up lightly.

2a) For MPI_T_CVAR_GET_INFO, I’m not seeing the conflict. The parameters are {int,string,int,int,MPI_Datatype,} so there is nowhere to pass MPI_COMM_WORLD *as a communicator, i.e. MPI_COMM*. Of course, MCW is a link-time constant handle, so its value can be used pretty much anywhere with suitable casting. I would not expect int george = (int)MPI_COMM_WORLD; to need the communicator represented by the symbol to exist.

You’re correct about MPI_T_CVAR_GET_INFO.  I overlooked the table 14.2 in section 14.3.2 that describes values returned in the bind out argument.  We’ll need to extend this table to include a session handle type.


2b) For MPI_T_CVAR_HANDLE_ALLOC, I like your option of a “not now” error. Alternatively, see (3b) below.

3a) For MPI_T_PVAR_GET_INFO, I’m not seeing the conflict (as for CVAR in (2a) above).

Agreed same as above in my response.


3b) For MPI_T_PVAR_HANDLE_ALLOC, would it be possible to attach the pvar to a skeleton mcw and always return dummy/default values (e.g. all counters would stick at zero) when queried? How much of mcw would need to exist (my assumption - none of it)? If some future action causes MCW to be created properly, i.e. MPI_INIT is called, then the pvar would be attached to it during that creation and start giving non-dummy/default answers. This change could be made irrespective of MPI Sessions.
MPI_T_INIT();
MPI_T_PVAR_HANDLE_ALLOC(…MCW…);
MPI_INIT();
// MCW already has PVAR attached

This sounds like a reasonable approach to me.


4) We should allow the session handle to be passed as the obj_handle so that CVARs and PVARs can be attached to MPI Sessions.

Yep, at a minimum we should extend the table 14.2


Cheers,
Dan.

On 27 Jan 2017, at 00:17, Pritchard Jr., Howard <howardp at lanl.gov<mailto:howardp at lanl.gov>> wrote:

Hi Folks,

I finally got around to a to-do item for the MPI sessions WG.  I’d said
I’d look through the MPI_T portion of the tools chapter of the standard
and see what consequences the MPI Sessions concept would have on that
section.

I came up with the following short list:

  *   terminology collision.  For performance variables, there is an MPI_T_pvar_session construct.  However, it seems to me this is sufficiently distinct from what we’re proposing for sessions that there should not be an issue.
  *   MPI_T_CVAR_GET_INFO   and MPI_T_CVAR_HANDLE_ALLOC.  These have a handle to a MPI object argument.  It is legal to pass MPI COMM WORLD/COMM SELF in as the argument.  So we’d need to figure out how to handle these cases in the context of an application that doesn’t explicitly call MPI_INIT or one of the other MPI functions that, according to our proposal, has the side effect of creating MPI_COMM_WORLD/SELF.  One option might be to return MPI_ T_ ERR_ CVAR_ SET_ NOT_ NOW error code.
  *   A similar problem exists for MPI_T_PVAR_GET_INFO and MPI_T_PVAR_HANDLE_ALLOC.  Curiously, there is no analogous MPI_T_ERR_PVAR_SET_NOT_NOW error code.

That’s what I came up with for first order items that would be impacted by Sessions, beyond minor languages changes in the text to indicate, for instance, that a Session handle could be passed to MPI_T_CVAR_HANDLE_ALLOC, etc.

Howard


--
Howard Pritchard
HPC-DES
Los Alamos National Laboratory

_______________________________________________
mpiwg-sessions mailing list
mpiwg-sessions at lists.mpi-forum.org<mailto:mpiwg-sessions at lists.mpi-forum.org>
https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions

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