The group is the easiest way to do the mapping from rank in window to ompi_proc_t, so it’s safe to say every window will have one (also, as a way of holding a reference to the ompi_proc_t). So I think it’s safe to say that every OSC module has a group handle somewhere (directly or through the communicator).
Remember that in some implementations of the MTL, a communicator ID is a precious resource. I don’t know where Portals 4 falls right now, but in various of the 64 bit tag matching implementations, it’s been as low as 4k communicators. There’s no need for a cid if all you hold is a group reference. Plus, a communicator has a bunch of other state (collective modules handles, etc.) that aren’t necessarily needed by a window. Brian On Nov 29, 2017, at 5:57 AM, Clement FOYER <clement.fo...@gmail.com<mailto:clement.fo...@gmail.com>> wrote: Hi Brian, Even if I see your point, I don't think a user request de free the communicator should necesserily lead to the communicator being deleted, only released from one hold, and available to be disposed by the library. I don't see objection to have the library keep a grab on these communicators, as the user give a handle to the actual object. I do agree the point of asking if we want to keep only information relevant to all OSC components. Nevertheless, what would the difference be between holding the complete communicator and holding the group only? Is group the smallest part common to every component? Clément On 11/28/2017 07:46 PM, Barrett, Brian via devel wrote: The following is perfectly legal: MPI_Comm_dup(some_comm, &tmp_comm); MPI_Win_create(…., tmp_comm, &window); MPI_Comm_free(tmp_comm); <use window> So I don’t think stashing away a communicator is the solution. Is a group sufficient? I think any rational reading of the standard would lead to windows needing to hold a group reference for the life of the window. I’d be ok putting a group pointer in the base window, if that would work? Brian On Nov 28, 2017, at 10:19 AM, George Bosilca <bosi...@icl.utk.edu<mailto:bosi...@icl.utk.edu>> wrote: Hi Brian, Let me first start with explaining why we need the communicator. We need to translate local to global rank (aka. rank in your MPI_COMM_WORLD), so that the communication map we provide make sense. The only way today is to go back to a communicator and then basically translate a rank between this communicator and MPI_COMM_WORLD. We could use the gid, but then we have a hash table lookup for every operation. While a communicator is not needed internally by an OSC, in MPI world all windows start with a communicator. This is the reason why I was proposing the change, not to force a window to create or hold a communicator, but simply because the existence of a communicator linked to the window is more of less enforced by the MPI standard. George. On Tue, Nov 28, 2017 at 1:02 PM, Barrett, Brian via devel <devel@lists.open-mpi.org<mailto:devel@lists.open-mpi.org>> wrote: The objection I have to this is that it forces an implementation where every one-sided component is backed by a communicator. While that’s the case today, it’s certainly not required. If you look at Portal 4, for example, there’s one collective call outside of initialization, and that’s a barrier in MPI_FENCE. The SM component is the same way and given some of the use cases for shared memory allocation using the SM component, it’s very possible that we’ll be faced with a situation where creating a communicator per SM region is too expensive in terms of overall communicator count. I guess a different question would be what you need the communicator for. It shouldn’t have any useful semantic meaning, so why isn’t a silent implementation detail for the monitoring component? Brian On Nov 28, 2017, at 8:45 AM, George Bosilca <bosi...@icl.utk.edu<mailto:bosi...@icl.utk.edu>> wrote: Devels, We would like to change the definition of the OSC module to move the communicator one level up from the different module structures into the base OSC module. The reason for this, as well as a lengthy discussion on other possible solutions can be found in https://github.com/open-mpi/ompi/pull/4527. We need to take a decision on this asap, to prepare the PR for the 3.1. Please comment asap. George. _______________________________________________ devel mailing list devel@lists.open-mpi.org<mailto:devel@lists.open-mpi.org> https://lists.open-mpi.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@lists.open-mpi.org<mailto:devel@lists.open-mpi.org> https://lists.open-mpi.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@lists.open-mpi.org<mailto:devel@lists.open-mpi.org> https://lists.open-mpi.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@lists.open-mpi.org<mailto:devel@lists.open-mpi.org> https://lists.open-mpi.org/mailman/listinfo/devel
_______________________________________________ devel mailing list devel@lists.open-mpi.org https://lists.open-mpi.org/mailman/listinfo/devel
