[mpiwg-sessions] Can I query a set even if I'm not in it?

Jeff Squyres (jsquyres) jsquyres at cisco.com
Thu Apr 28 12:17:21 CDT 2016

On Apr 26, 2016, at 4:11 PM, Bland, Wesley <wesley.bland at intel.com> wrote:
> Apologies if we’ve covered this and I’ve now forgotten, but it’s something that came up in the FTWG con call today. If I’m not in a set, am I still able to get the group it describes?
> An example is because the set names are easily serialized (because they’re strings), I could pass a set name around so that someone who wasn’t in the set could have access to it and therefore ask the runtime to create a group from it. In the group world, this is allowed:
>> Section 6.4.2 (MPI 3.1 p. 230 line 4-5) - … a process may also define a group that does not include itself. 

FYI -- that's section 6.3.2, not 6.4.2.

> This has advantages and disadvantages. The advantage is that we could do things like create inter-communicators without the bridge_comm as long as you have some other way of getting the set name. We decided on the last call that this was important. In the context of fault tolerance, it *might* be possible to do in-place replacement if we have the ability to touch all sets from anywhere (HUGE might there).
> The downside is that you have to be able to get the definition of any set from anywhere, which could have scalability issues (having to keep track of all the sets and how they overlap would be an O(p*s) problem, which we’re trying to avoid).

In principle, I don't think I have a problem with a process asking for a group for a set of which it is not a member.  However:

1. You're correct about the scalability issues.

--> This exposes an ambiguity in MPI_Session_get_names(): does that return *all* set names, or just sets to which the querying process belongs?  I'm in favor of the latter.

2. There's also an issue about the uniqueness of set names.  E.g., we defined that every process is part of mpi://SELF, but each of those sets are distinct from each other.  E.g., when process X refers to mpi://SELF, is it referring to its *own* mpi://SELF, or the mpi://SELF relative to some other process?

Point #2 alone may dictate that set names are only meaningful in the process in which they were queried / returned by the runtime.

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

More information about the mpiwg-sessions mailing list