... Baker1
Current address: University of Portsmouth, UK
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... environment2
A particularly strong requirement is that in no circumstances must the software leave resource-wasting orphan processes lurking after an untidy termination. This very undesirable behaviour has affected some early implementations of MPI in the past.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... systems3
In the short-to-medium-term--before Jini software is widely installed--we might have to provide a version of the MPJ reference implementation that is unbundled from Jini. Designing for Jini protocols should, nevertheless, have a beneficial influence on overall robustness and maintainability. Use of Jini implies use of RMI for various management functions.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... automatically4
Perhaps one could exploit the two-phase commit of the Jini transaction model to make checkpointing truly fault-tolerant...
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... occur5
We notice that an MPJ job as a whole has some characteristics of a single Jini transaction. While interesting, this analogy is not clearly useful.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... called6
This is a change to the API of mpiJava [2], for example, where the main method is static and the default communicator is a class variable. The approach here (which follows more closely DOGMA [8] or JMPI [5]) seems to fit more naturally with RMI, and allows for the possibility of running several MPJ processes as threads in a single JVM (although probably that won't be supported in the initial reference implementation).
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... with7
The args array passed to main only holds command-line arguments after MyMPJApp.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... daemon8
Using an activatable object is not essential, but it can reduce resources consumed by a daemon that is not in use, and provides an automatic way for the daemon to be restarted after crashes of the host system.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... table9
Not its RMI registry!
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... environment10
In this context, arguably, the biggest concern is correct synchronization.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.