Communication in Java

The standard Java API provides a simplified interface to Internet sockets. This interface hides much of the ugly detail involved in socket-programming at the at the traditional C/UNIX level. The java.net interface provides less flexibility than using the system calls directly. On the other hand, Java's built-in support for threads adds some flexibility in scheduling communications that is missing from raw C.

We will give an example of socket programming in section 3.1, but traditionally this has not been a popular paradigm in the parallel processing world. Scientific programmers have expected to program inter-process communication at a higher level, if at all. More successful schemes include

• Message-passing through language-level support [24, 15] or higher-level library interfaces [14].
• Data parallelism. We restrict the definition of ``data parallelism'' to cover algorithms that achieve parallelism through operations on distributed arrays. Synchronization is usually limited to bulk synchronization occuring naturally through collective operations.
• Communication through shared memory or shared objects. Some more or less intricate mechanism for inter-process synchronization is usually provided.

The case studies in the rest of this article restrict themselves to message-passing and data parallelism. As observed in the previous section, communication through true shared memory is already implicit in the Java thread model. Communication through remote objects is undoubtedly a natural and important paradigm in Java, especially for access to remote services [27, 22, 21], but we will not discuss it further here.

An orthogonal issue is whether the high-level libraries used to implement these paradigms (presuming class-library implementations) should be written in Java on top of the standard API, or whether they should be implemented as direct interfaces to native code. We will have more to say about this later.