Process groups

A group, or process group, defines some subset of the processes executing the SPMD program. Groups have two important roles in HPJava. First are used to describe how program variables such as arrays are distributed or replicated across the process pool. Secondly they are used to specify which subset of processes execute a particular part of the code.

In HPJava groups are represented by objects of class Group. There are several ways to create group objects. The most common is to use the constructor for one of the subclasses representing a process grid. The class hierarchy of groups and process grids is shown below

A member of Procs1 describes a one-dimensional ``grid'' of processes, a Procs2 is a two-dimensional grid, and so on. As a special case, a member of Procs0 denotes a group containing a single process. The constructors for these classes generally take a list of extents specifying the shape of the grid. The constructors select the processes of the grid from the set of processes that collectively invoke the constructor; if the specified size of the grid is larger than this set of processes, an exception occurs.

The general Group class can also describe restricted groups. These are subsets of process grids defined by fixing some of the process coordinates associated with the grid to have single values. In other words, they are slices of process grids.

Active Process Group

The active process group is a slightly subtle idea. You may wish to skip the rest of this section on a first reading, but the ideas are quite important for a deeper understanding of the language.

A straightforward use of grids was illustrated in a previous section, where the elements of various arrays were distributed over the processes in a grid. Grids and groups in general have another important role. The language has a built-in idea of an active process group. At a typical point of execution of a typical process, viewed as part of the parallel program, some group of peer processes will be following "the same" control path through the program. This group can quite naturally engage in "collective behaviour". The cooperating group is called the Active Process Group (APG) for that point of the program. There may be points of program execution where all processes are performing completely independent tasks. HPJava regards this as a special case where all processes belong to active groups of one - containing just themselves.

The on construct seen in a previous section is an obvious example of a program construct that affects the active process group. Inside the construct on(p) the APG is reduced to p. More subtly, the overall construct also affects the APG, slicing it into smaller, independently operating, restricted groups. Note an on(p) construct can only be executed if p is a subset of the process group already active. Similarly an overall(i = x for ...) construct is only allowed at a point where range x is distributed over a dimension of the effective APG.

Coherence

Any program variable has a home group. For distributed array elements, the home group is a restricted slice of the group over which the array as a whole is distributed. For variables that are not distributed array elements, the home group is just the APG in effect at the point where the variable was declared or created.

Each process in the home group of a variable holds a copy of the variable. A variable is coherent if all of those processes always update their local copies of the variable at identical program points, and with identical values. Coherence is a good thing, and in most well-written HPJava programs, most variables will be coherent. We already encountered an example of this with the replicated matrices a and b in the previous section. It is especially desirable for expressions used in control constructs to be coherent. Many collective methods, such as collective communication operations, will require their arguments to be coherent.

It is possible to define formal rules for preserving coherency in HPJava, but we will not do that here. It might even be possible for an HPJava compiler to enforce some such rules. However there are many practical examples where careful use of incoherent variables is convenient. Also, the most obvious schemes for checking that all updates of every variable preserve coherency seem quite costly. So for now the language does not require coherence. It is just regarded as good programming practice.

Next: Communication