Sketch of a ``Device-Level'' API for MPJ

In this section we turn to the issue of how to implement MPJ once a reliable group of processes has been established. Whereas the previous section was concerned with true distributed programming where partial failure is the overriding concern, this section is mainly concerned with concurrent programming within a single JVM--a reliable environment.

We assume that the MPJ user-level API will be implemented on top of a ``device-level'' API, roughly corresponding to the MPID layer in MPICH. The following properties are considered to be desirable for the device-level API:

1. It should be implementable on the standard Java API for TCP sockets. In the absence of select, this essentially forces introduction of at least one receive thread for each input socket connection.
2. It should be efficiently implementable (and probably will be implemented) with precisely this minimum required number of threads.
3. It should be efficiently implementable with at least two protocols:

   a) The naive eager-send protocol, assuming receiver threads have unlimited buffering.

   b) A ready-to-send/ready-to-receive/rendezvous protocol requiring receiver threads only have enough buffering to queue unserviced ``ready'' messages.

4. The basic operations will include isend, irecv and waitany (plus some other ``wait'' and ``test'' operations). These suffice to build legal implementations of all the MPI communication modes. Optimized entry points for the other modes can be added later.
5. (Probably) all handling of groups and communicators will be outside the device level. The device level only has to correctly interpret absolute process ids and integer contexts from communicators.
6. (Maybe) all handling of user-buffer datatypes is outside the device level. The device level only deals with byte vectors.

• Minimal API
• Implementation notes
• Eager send protocol
• Rendezvous protocol