Why IPC Requires OS Support
The isolation problem
The memory-protection mechanisms that keep processes safe (separate address spaces, MMU-enforced page permissions) also prevent them from sharing data directly. Process A cannot read Process B’s memory because A’s page table has no mapping to B’s physical frames. This is the correct default for security, but it means that processes that need to communicate must go through the kernel.
The kernel as intermediary
The OS provides Inter-Process Communication (IPC) mechanisms as system calls. The kernel acts as a trusted mediator: it can read both processes’ memory (it runs in kernel mode) and can copy data between them, or it can set up shared memory regions that appear in both processes’ address spaces.
Design dimensions of IPC
| Dimension | Questions |
|---|---|
| Capacity | How much data can be transferred in one operation? Bytes? Messages of arbitrary size? |
| Synchrony | Does the sender block until the receiver reads? Does the receiver block until data arrives? |
| Addressing | How does a process name the communication partner? Direct (PID) vs indirect (mailbox/pipe name) |
| Relationship | Must the processes be related (parent-child)? |
| Buffering | Is there a kernel buffer? What is its capacity? |
UNIX IPC mechanisms at a glance
| Mechanism | Related processes? | Data unit | Ordered? | Buffered? |
|---|---|---|---|---|
| Signals | Any (same UID) | One bit + a small integer | No ordering guarantees | No — signals may be merged |
| Pipes | Related (parent-child, siblings) | Byte stream | Yes, FIFO | Yes, kernel pipe buffer (~64 KB) |
| Named pipes (FIFOs) | Any (by path name) | Byte stream | Yes, FIFO | Yes |
| UNIX-domain sockets | Any (by path name) | Byte stream or datagrams | Yes (stream), best-effort (datagram) | Yes |
| Shared memory (shm) | Any (by key) | Direct memory access | Application’s responsibility | None |
| Message queues | Any (by key) | Structured messages | Yes, by priority | Yes |
| File descriptors (SCM_RIGHTS) | Any (via UNIX-domain socket) | File descriptor | Yes | Yes |
Why not just use files?
Using the file system for IPC (process A writes to a file, process B reads it) is possible but slow: every operation goes through the file-system stack, requires disk I/O (or at least buffer-cache overhead), and incurs the cost of name look-up and permission checks. It also lacks synchronisation — B must poll or use inotify to know when A has written new data. Kernel IPC mechanisms are designed for low-latency, synchronised data transfer without touching the disk.
The Tripos focus
The exam concentrates on three mechanisms: signals (lightweight notification), pipes (byte-stream between related processes), and named pipes (pipes that exist in the file-system namespace, allowing unrelated processes to connect). Shared memory may appear in extension questions, but the core comparison is signals vs pipes vs named pipes.
Summary
- Process isolation blocks direct data sharing; the kernel must mediate IPC.
- IPC mechanisms vary in capacity, directionality, synchrony, and addressing.
- UNIX provides signals (lightweight), pipes (stream, related processes), named pipes (stream, unrelated), sockets, shared memory, and message queues.
- Signals are unreliable for data transfer; pipes and named pipes are the practical choices for reliable byte-stream communication.