14 Parallel programming: MPP architectures

1. Code for execution in the MPP environment alone should be delimited by the ftc identifier mpp (i.e., cstart mpp $\dots$ cend).
2. Parallelism is controlled by a flag variable mpp_state in "common/cmpp", which should be set by the programmer to reflect the current state according to the following.

   0	MPP not active -- normal sequential job
   1	multiple processes doing identical work
   2	multiple processes doing complementary work

3. Binary i/o on named files is to disk through master process only; unnamed files are implemented as a set of global arrays through the GA toolkit. As far as possible, programmers should use the reserv subroutine to preallocate file records, and disk accumulation operations should use the (new) accw routine rather than separated calls to lesw and sreibw.
4. Unmodified sequential code runs with mpp_state$= 1$, and identical work is done by each process. Input data, and binary reads on named or unnamed files is performed and broadcast by master process. Output and binary writes are performed by master process, and ignored in other processes.
5. Truly parallel code begins by setting mpp_state to 2, and then each process does unique work. At least in the initial implementation, i/o on named files is forbidden except by the master process. Binary reads, writes and accumulates are implemented as accesses to the relevant global array (ga_get, ga_put, ga_acc). Many parallel algorithms are in this way realised with access to global data purely through existing i/o calls; existing strategies to page data to/from disk when memory is scarce can map directly to the efficient use of local copies of global data in the distributed memory MPP context.
6. Dynamic load-balancing can be implemented through the nxtval subroutine.
7. Second-level parallelism where, for example, any single process in the above description runs on a multiprocessing shared memory node, is in no way precluded by these structures.