Persistence and Communication State Transfer in an Asynchronous Pipe Mechanism - Cloud, Grid and High Performance Computing: Emerging Applications - page 243

face for accepting and establishing connections
between two MPI applications, enabling com-
munication with MPI_Send() and MPI_Recv().
Although fault-tolerance may be incorporated
into this mechanism, current projects (Fagg and
Dongarra, 2004; Batchu et al., 2004; Bouteiller et
al., 2006; Gropp and Lusk, 2004) are focused on
fault-tolerant IPC within an application.
In the MPI model, each process is identified
by an integer rank. Elegant and simple, this model
works very well on SPMD applications where the
number of processes is known and fixed. Phoenix
(Taura et al., 2003), for example, modifies the
process naming scheme so that processes may join
and leave the computation without the need to re-
assign ranks. When coupling multiple applications
in a workflow, it is useful to have a user-intuitive
convention to identify communication endpoints
(Chan and Abramson, 2007, p. 6).

connect processes. However, it lacks support for
communication fault-tolerance.

Π-CHANNELS: A PERSISTENT
PIPE MECHANISM

A π-channel is an enhanced unidirectional
(MRSW) pipe that has a unique user-specified
string name and a FIFO sequence of arbitrary-
length typed data segments, each treated as in-
divisible units. Fault-tolerant communication is
achieved by persistence, enabling π-channels to
be created and written to at any time, independent
of the sink/reader, thus encouraging temporal
decoupling.
During π-channel creation, if the matching
reader is known, a direct connection (if possible) is
used to efficiently transfer pipe segments. Due to
persistence (Chan and Abramson, 2007), delivery
of the π-channel to the π-Space continues (Figure
2a). This enables π-channel writes to proceed even
if the link and/or reader have failed during com-
munication. At this point, the pipe segments will
be written to the π-Space (Figure 2b). When the
reader resumes, a communication state transfer
re-establishes the connections between the reader,
the π-Space, and the writer.

Generative Communication Models

Linda (Carriero and Gelernter, 1989) is a genera-
tive communication model that features decoupled
communication. In Linda, processes communicate
by posting and retrieving ordered sequences of
values called tuples onto a logical shared space
called tuplespace. Its elegance has inspired many
systems such as Sun's Javaspaces (Freeman et
al., 1999), and IBM's T-spaces (Wyckoff et al.,
1998). The Linda tuplespace model encourages
decoupled communication along two dimensions.
First, tuples are posted and retrieved anonymously
from tuplespace, achieving space decoupling.
Second, since tuples are persistent, temporal
decoupling is possible, allowing non-concurrent
processes to communicate.
Workflows require efficient data transfers,
which is challenging to achieve in Linda. Exten-
sions have thus been proposed, e.g. WCL (Row-
stron, 1998) supports bulk transport of tuples.
Taskspaces (Sterck et al., 2003, 2005) provide
direct communication using the tuples to identify
communication endpoints (IP/port) and TCP to

π-Channels: Programming Model
and Semantics

Table 1 summarises the API for π-channels. This
is inspired from file-based I/O and connection-
oriented socket communication. The key dif-
ference is that a thread is employed to receive
data asynchronously. The read/write operations
resemble the standard Unix I/O operations, with
specifications of the segment data type, for het-
erogeneous communication.