SP2 Process Spawning

The SP2 version of PVM that uses MPI for internal communications appeared initially not to require any alteration. Unfortunately, when required to spawn N processes, it spawned an extra process to manage communication with the daemon, effectively allowing true nonblocking communication between on and off machine nodes, as shown in Figure 5 for a four-task application. In other words, MPI applications have one extra process that they cannot communicate with, because it is dedicated to relaying messages for the PVM system.

  
Figure 5: SP2MPI PVM using an application host task to manage nonapplication message routing

The library also had other shortcomings in its ability to handle re-entrance of MPI_Init. In particular, its default failure mode was pathological, and it did not use a private communicator internally, but instead used MPI_Comm_World. Two separate systems [#SP2MPI##1#] are currently being evaluated that resolve these problems:

1. A modified SP2MPI port that creates the required number of tasks, each of which individually opens a socket to the spawning PVM daemon for out of application communication. This version works for both PVMPI and conventional PVM applications and may replace the currently used method.

2. An SP2 viewed as a cluster of RS/6000 workstations, but with the application spawned as in the SP2MPI version using the IBM POE[#IBM##1#] called from a special tasker. The tasks individually connect to their local host daemon, after an extra layer of handshaking that correctly sets up their task data structures (including the parent task identity).