Return to the Lecture notes Index

Lecture 10 (Monday, February 7, 2000)

Interprocess Communication (IPC)

Motivation:

Why not threads?

Why not just shared memory?

Universal IPC Facilities

(Review: Signals and pipes were required for Project #1)

Signals – a.k.a software interrupts

Pipes

Ptrace

Sockets

System V IPC

Semaphores, message queues, shared memory,

Common elements

Implementation

Mechanisms

Message Queues

Shared Memory


SYVR4 Streams

More flexible than IPC, but can function as IPC and is used to implement some IPC facilties





/proc File System

Mach IPC

Mach is an operating system based on a microkernel architecture. This means that many of the josb that are typically part of the operating system's kernel are actually user processes. This makes an interesting application for IPC. It is in fact the case that IPC is necessary for operating system components implemented as user processes to interact with each other. In many ways, IPC is part of the foundation for a microkernel based operating system -- not the other way around. The file system, pager, memory management, &c are all implemented as user-level tasks outside of the kernel -- they interact with the kernel via the Mach IPC

Some key goals of the designers of Mach IPC included:

In the Mach model, data is formed into messages. These messages are then passed among processes. A process receives a message at a port. A port is a queue of messages.

Ports

Each port's queue has a finite capacity. When the queue is full the senders block; when it is empty, the receivers block. Senders must hold capabilities to access a port. These capabilities come in two flavors: read and write. Many processes may have write capabilities to a port, but only one may have read capability.

In the context of Mach, a capability is a name for a port that is unique within a process's space. Two different processes may have two different capabilities representing the same port. Capabilities are reference counted.

 

There are some special ports:

Backup Ports

Ports can have backup ports. If a port is deallocated (freed) and messages are sent to this deallocated port, the backup port will recieve them.

 

Port Sets

Port sets implement similar functionality to the UNIX select() function. One important difference is that port sets do not suffer a performance degredation if there are many ports in the set -- access time is constant. One can view a port set as a common queue for several ports. Since the message itself contains the original destination, the intended recipient can be discovered.

Messages

Messages contain the data that is being sent from process to process and the metadata needed to transport and interpret it. The actually user data may be contained within the message, or it may be referenced in shared memory. Small amounts of data contained within the message itself are known as in-line memory. Larger amounts of data that are only referenced within the message are known as out-of-line memory. Out-of-line memory is shared using a copy-on-write approach. The memory is shard by both tasks, until either tasks write to it, at which time a private copy of the page is made.

Messages may be sent (msg_send), received (msg_recv), or sent, when a reply is expected (msg_rpc). msg_rpc() is typically used to implement remote procedure calls.

Type descriptor