[mpiwg-tools] Open MPI pvar scheme

[Schulz, Martin]

On Nov 12, 2013, at 12:51 PM, "Jeff Squyres (jsquyres)" <jsquyres at cisco.com>
 wrote:

> On Nov 11, 2013, at 7:03 PM, "Schulz, Martin" <schulzm at llnl.gov> wrote:
> 
>>>> I think it would be better to programmatically express such relationships -- i.e., something new for MPI-4.
>> 
>> I agree with that, but I see it more as an MPI 3.1 feature. Is it really a major concept?
> 
> I thought it was "more" than a minor/bug fix concept... and therefore should wait until 4.

We need to finally discuss and decide that (as the forum) - this will definitely be on the agenda in December.

>>> Er... I don't understand.  Why can't the enum strings change?  I think they can change at any time.
>> 
>> So that's a good question - I was assuming (at least that's how I always thought about it) that the same rules as for variables and all their metadata apply here - once read, a description cannot change and an enumeration type can worst thing grow. It is correct, though, that we didn't specify that explicitly - perhaps we need to do that. The only text that comes close is "The second datatype class, enumeration datatypes, describes variables with a fixed set of discrete values.".
> 
> Mmm.  Yes.  This *implies* that they don't change, but one could argue different meanings of "fixed set".

I know, this is ambiguous.

> 
>> Having strings change underneath would be a real problem for the string interface, since it makes the assumption that you can run queries against a string more than once and get the same string.
> 
> It sounds like you are introducing a new requirement, then: you want non-mutable strings, but the ability to have things change over time (e.g., new NICs added or old NICs dropped).

Well, I think we have two separate issues here:
- Should strings be allowed to change? In particular, should we allow enumerations to change on the fly? I think the answer to this should be no, since this would create race conditions and it would prevent tools from caching any data (that's why we did it for the variable metadata and for the types it seems even more relevant)
- Do we need a mechanism to describe changing variable arrays? This is more a requirement question - how is this in your case? Will you support changing number of NICs and how are you planning on doing that?

> 
>>> I think what you might be saying is that the *count* on a handle can't change -- right?  I.e., MPI_T currently has no way of saying, "There were N values when you called pvar_handle_alloc() for this pvar, but now this pvar has M values."
>> 
>> Yes, but the count can change when you get a new handle.
> 
> That would be fairly hellish for an implementation: session/handle X has N values, but simultaneously, session/handle Y of the same pvar -- which just happened to be created after session/handle X -- has M values.
> 
> Meaning: the implementation has to track two entirely different views/counts of the same pvar.

Well, wouldn't that be up to the implementation? If it doesn't make sense for a particular case, then an MPI can always return the same count. I agree, if an MPI does do it that way, it won't be easy.

> 
>> Yes, that's what I meant with "doesn't have to be at the moment" - any variable that has the potential to have a count that is not 1 is affected.
> 
> ...which is *any* variable, right?

Yes - what I meant was that if there is a variable that a particular MPI implementation always decides to return 1 for, then you will probably never need a matching enumeration variable. However, just because it returns 1 once, it doesn't mean that it is guaranteed that it will stay that way for the rest of the run or during the next run. Hence, matching enumeration variables make sense even for variables that have a count of 1.

Martin


> 
> -- 
> Jeff Squyres
> jsquyres at cisco.com
> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
> 

________________________________________________________________________
Martin Schulz, schulzm at llnl.gov, http://people.llnl.gov/schulzm
CASC @ Lawrence Livermore National Laboratory, Livermore, USA