Message Passing

Overview

Message passing refers to a means of communication between

• different threads within a process
• different processes running on the same node
• different processes running on different nodes

When messages are passed between two different processes we speak of inter-process communication, or IPC.

Message passing can be used as a more process-oriented approach to synchronization than the "data-oriented" approaches used in providing mutual exclusion for shared resources.

The two main dimensions

• Synchronous vs. asynchronous
• Symmetric or asymmetric process/thread naming

Simple Message Passing

One process/thread is the sender and another is the receiver

Symmetric Naming

    .
    .
    send(Q, message);
    .
    .

    .
    .
    receive(P, &message);
    .
    .

Asymmetric Naming

    .
    .
    send(Q, message);
    .
    .

    .
    .
    receive(&message);
    .
    .

Here the receiver will accept a message from any sender. The sender can pass its own id inside the message if it wants.

Synchronous Communication

P and Q have to wait for each other (one blocks until the other is ready).

Asynchronous Communication

Underlying system buffers the messages so P and Q don't have to wait for each other. This is less efficient due to the overhead of managing the buffer.

Client-Server Communication

A system in which the receiver (server) does care about the sender and is normally responsible for sending a reply message.

Knowledge of the sender can be implemented by

• Making the sender id a parameter to the receive operation
• Passing in the sender id as part of the message

Client-Server communication is basically synchronous, using the rendezvous as a primitive for building up more sophisticated communication mechanisms, including asynchronous ones.

Rendezvous

The client blocks while the server computes and sends back the reply.

If the computation may take a long time, and the client has useful work to do, the rendezvous action should be kept short and some other way can be found to get the result back to the client.

Note that because the client blocks while the response is sent back, we say message exchange is atomic.

Callback

The client calls the server with the input data and its id and doesn't block. Sometime later, the server will call the client and pass the result.

Receipt

The client calls the server, passing in the input data and receiving (immediately) a receipt from the server; later, the client contacts the server again, using the receipt to get the result. (Supposedly, dry cleaners and photo developers work this way.)

Mailbox

The client gives the server the address of the mailbox where it wants the result to go; the client retrieves the result later.

A mailbox can also be used to send the input data to the server:

Relay

A relay implements a fully asynchronous, no-wait send, and is used only when no reply is necessary. The relay blocks "on behalf of" the client.

Buffer

This one is classic.

Channels

Instead of considering the identities of the processes as central, some systems view the communication channel as the named entity through which information is passed.

One example is the occam language. In this language, channels must be laid out at compile time, making client-server programming (in which a server can serve multiple clients) difficult.

Unix Pipes

A pipe is similar to a mailbox, but

• It's for untyped data only
• It's really an abstraction for an I/O device (using Unix read and write system calls)

Pipes are inherited by forked processes. Be careful when communicating with children; you might read your own message.

Also note that Windows has named pipes too. And furthermore, some programming languages have pipes in their APIs.

Unix Messages

System V Unix introduced arbitrary typed messages and the following system calls:

msgget

creates or establishes a connection to a message channel; returns a channel descriptor.

msgsnd

sends message through a channel (one of the arguments is a descriptor returned by msgget).

msgrcv

receives message (using a descriptor returned from a previous call to msgget).

Sockets

Sockets are much more widely used than System V messages. (At least I think they are.) We'll cover them later since they are so important.

Things to Note

On Communication

• Synchronous Communication is like the telephone.
• Asynchronous Communication is like mail.
• Implementing asynchronous communication using a buffer object (or thread) is like an answering machine. (Do you see how?)

On Naming

• occam uses dedicated channels; names of both the sender and receiver are required. Most efficient. Least flexible.
• Linda uses broadcast communication only. Neither the sender or the receiver name each other! This is like a bulletin board.
• In Ada, only the receiver, not the sender is named. This is like the telephone without caller id.

On Perl

Perl's got quite a lot of functions (and packages) in the whole message passing area. See perlipc.