Partly, this window related information is useful whatever mechanism the
standard defines for accessing it. There are two issues:
1o. caching window attributes leads as you say to more elegant code.
Implicit caching with MPI_WIN_BASE, etc ensure that these attributes
are available to any subroutine that is handed down the MPI_Window,
this is useful information.
2o. The second point is minor, namely in the example the base of the
window is passed down from some higher level in the call tree.
Memory allocation can be far removed from the place where MPI_Put
and MPI_get are used. One current practice among FORTRAN programmers
is for the driver program to allocate a large chunk of memory that
is used later by internal subroutines. Surely the Forum has thought
of this last point.
****
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.
****
Fair enough but an MPI_Window is created from a collective operation
on some communicator. It may be that I do not understand MPI_Win_barrier
correctly and that it will do the work of MPI_Barrier.
****
We hesitated between a group, and an array of ranks. Is the later less
heavy?
*****
Lets try:
MPI_Comm_rank ( comm, &me ) ;
MPI_Comm_size ( comm, &np ) ;
My group code looks like this:
MPI_Comm_group ( comm, &Group ) ;
for ( i=0 ; i<np ; i++ ) ranks[i] = i;
for ( i=0 ; (1<<i)<np ; i++ ) {
ranks [ me^(1<<i) ] = MPI_PROC_NULL ;
MPI_Group_excl ( Group, np, ranks, &NGroup[i] ) ;
ranks [me^(1<<i) ] = me^(1<<i) ;
}
...
for ( i=0 ; (1<<i)<np ; i++ ) {
MPI_Win_post ( NGroup[i] , 0 , window ) ;
...
}
An array based looks like this:
for ( i=0 ; (1<<i)<np ; i++ ) ranks[i] = me^(1<<i) ;
...
for ( i=0 ; (1<<i)<np ; i++ ) {
MPI_Win_post ( 1, &ranks[i] , 0 , window ) ;
}
***
See above - no reason to assume that an implicit communicator is associated
with a window. .
******
Page 136 of the MPI1.1 Standard defines a communication context as
follows:
A context is a property of communicators (defined next) that allows
partitioning of the communication space. A message sent in one context
cannot be received in another context. <... deleted ...> Contexts
are not explicit MPI objects; they appear only as part of the
realization of communicators.
MPI_Window objects are not associated with a communication
context in the sense that there is no guarantee that an MPI_Put will
not affect the storage associated with distinct overlapping windows.
Page 74 of the Nov 7 draft specifies:
The same area in memory may appear in multiple windows, each
associated with a different communicator. However, concurrent
communications to distinct, overlapping windows may lead to
erroneous results.
How is this association of communicators and windows effected?
and how associating different communicators with overlapping
windows prevents incorrect results? Is this through calls to
MPI_Barrier? To return to the initial question, do MPI_Window
object have an associated communication context (not a communicator)
that is under their responsibility to maintain or preserve in the
case of overlapping windows?
BTW. As anyone looked at the 1sided communications in other
contexts than multicomputers, e.g. smart cards? This may provide
some useful insight?
Thanks,
Joel.