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 https://lists.open-mpi.org/mailman/listinfo/devel