Some alternatives seems to be:
1. initialize a window near to where R is declared and
1.a: get the base address from the MPI_WINDOW_BASE attribute
1.b: pass the base address of the mpi_window to the called subroutine
1.c: change the call to MPI_Put so it will compute the appropriate
offset from a pointer into the local window.
2. Create a window inside the called subroutine
2.a: delete the window upon return of some_sort_of_reduce
2.b: create a persistent window (static in C) that is resized whenever
the base address changes or its current length is too small.
Option 1.a corresponds to the current standard, 1.b is awkward because
the call to some_sort_of_reduce appears long after R has been allocated
One drawback with passing down a window to some_sort_of_reduce
(1.a & 1.b) is that the caller must be aware of the callee using one-sided
One drawback with creating all necessary windows inside
some_sort_of_reduce is that the buffer S can be large. 1.c. has been
discussed on the mpi-1sided list.
The difference 1.a vs 1.b is btw passing a window which has hidden
attributes, or passing a window + the attribute(s) as explicit
parameter(s). Cached attributes lead to a more elegant, OO style, with all
info attached to one object, Is this the issue that you raise?
I would like to be able to find out whether a window argument is still
valid, e.g. should the 'relevant' communicator be passed as argument
along with the window. The communicator that is passed to
MPI_Win_init is only a performance hint: should one pass the
underlying group along with the window instead? Could the relevant
information be extracted from the window, e.g. something of the sort:
mpi_win_comm (window, &comm) ;
mpi_barrier (comm) ;
or mpi_win_group (window, &group) ;
mpi_group_comm (group, &comm) ;
mpi_barrier (comm) ;
Your last example is invalid, one can create a communicator only as a
subset of a preexisting communicator. More significantly, do we
assume that a window is attached to an implicit communicator? There
is no reason to do this, from an implementation viewpoint; a windo
clearly has an attached group, but it may not need a dedicated
communication context. Thus, it makes sense to extract a group from a
window, but it makes less sense to extract a communicator.
A last point is that when the procedure some_sort_of_reduce implements
a recursive doubling where each process talks alternatively to one of
its neighbor (i.e. Pi <-> P(i^^(1<<j))) the MPI_Group argument of
synchronization procedures MPI_Start, MPI_Post becomes a bit heavy.
It seems that for p processes, log(p) groups need be created at least
on the initial call to some_sort_of_reduce or in a separate initialization
We hesitated between a group, and an array of ranks. Is the later less
Is it correct to describe MPI_Window objects as communication contexts
given that a specific window is not tied to anyone communicator except as a
performance hint in MPI_Win_init? Would it make sense to define the
matching procedures for MPI_Comm_compare, MPI_Comm_size, MPI_Comm_dup
(possibly with a new user-allocated buffer area), etc?
See above - no reason to assume that an implicit communicator is associated
with a window. .