Typically the communication schedules described in this chapter have only three public members: a constructor, a destructor, and an execute member.
Usually the constructor is passed all the detailed information describing how the input and output data is organized and how it is to be transformed. This includes the array descriptors and any parameters of the transformation. The constructor may perform extensive processing on these arguments to convert them into a simplified list of data movements. In some cases this processing may involve exchange of information--ie, communication--between the active processes. A schedule constructor should always be treated as a collective operation. As usual with arguments of collective operations, every member of the active process group must pass consistent arguments to the schedule constructor call. In particular this means that any simple value passed to a schedule constructor (any argument that is not a local component of a collective object such as a DAD, or a vector of local array elements associated with a DAD) must have identical values in every process.
Local segment addresses of input and output arrays--the vectors where individual array elements are stored--are usually not passed to the schedule constructor. Instead these addresses are passed to the execute member. One practical reason for not storing the data pointers in the schedule itself is that these vectors are typically allocated by the user, outside control of the library. The user's program may be written in a programming language other than C++. Cacheing pointers to memory allocated and managed outside the library itself can cause problems in some programming environments--especially in garbage-collected languages such as Java. Another advantage of specifying the data pointers at execution time rather than schedule construction time is that in principle it allows the same schedule to be used with different arrays, providing corresponding arrays have identical DADs.
The execute member nearly always involves communication. It should of course be treated as a collective operation, executed by all members of the active process group.
Most schedule constructors will access the apg variable. The state of this variable should accurately describe the set of processes involved in creating the schedule. The active process group at the point of execution of a schedule should be the same as the active process group at its point of creation.
The following sections describe the interfaces of the schedule
classes. The choice of transformations in the current schedule library
has been strongly influenced by HPF. Apart from a handful of
generic operations like Remap, Gather, Scatter and
WriteHalo, most of the schedules are designed to support
the specific array syntax and array transformational intrinsics
of Fortran 90
.
Focussing on Fortran provides a concrete standard with respect to which
some kind of completeness can be achieved.
In the interfaces given in the following sections, only the constructor and the execute members will be exhibited. Base classes (public or otherwise), members of base classes, destructors, etc, will be suppressed. Subsections describing the constructors detail any restrictions the arguments must satisfy. Subsections describing the execute members specify the effects of the schedules. Below we briefly discuss various terms and notations used, following the subheadings used in the schedule definitions.