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