← Back to all projects

UNIX IPC STEVENS VOL2 MASTERY

Interprocess Communication is the backbone of every modern Unix system. When you run `ls | grep foo`, you're using pipes. When PostgreSQL coordinates between its processes, it uses shared memory and semaphores. When your web server handles thousands of connections, it uses message queues and synchronization primitives.

Sprint: Unix IPC Mastery - Stevens Vol 2 Complete

Goal: Master every Interprocess Communication mechanism in Unix by working through W. Richard Stevens’ “Unix Network Programming Volume 2: Interprocess Communications.” You’ll deeply understand how processes share data and synchronize—from simple pipes to complex shared memory regions, from local semaphores to remote procedure calls. By the end, you’ll know exactly when to use each IPC mechanism, understand the trade-offs between POSIX and System V APIs, and have built real systems that coordinate multiple processes.

Why Unix IPC Matters

Interprocess Communication is the backbone of every modern Unix system. When you run ls | grep foo, you’re using pipes. When PostgreSQL coordinates between its processes, it uses shared memory and semaphores. When your web server handles thousands of connections, it uses message queues and synchronization primitives.

Historical Context

W. Richard Stevens wrote the definitive treatment of Unix IPC in 1999, covering mechanisms that date back to:

1970s: Pipes (original Unix)
1983: System V IPC (shared memory, semaphores, message queues)
1988: POSIX standardization efforts began
1993: POSIX.1b real-time extensions (including IPC)

Real-World Impact

According to research on IPC performance analysis:

Unix domain sockets perform 2x faster than TCP/IP for local communication
Shared memory remains the fastest mechanism for bulk data transfer
Named pipes (FIFOs) are still widely used for reliability and simplicity
Message queues provide natural request/response patterns

Modern systems like ByteDance’s Shmipc achieve 4x throughput improvements using shared memory IPC.

The IPC Landscape

┌─────────────────────────────────────────────────────────────────────────┐
│                        UNIX IPC MECHANISMS                               │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                          │
│  ┌─────────────────────┐    ┌─────────────────────┐                     │
│  │   DATA TRANSFER     │    │   SYNCHRONIZATION   │                     │
│  ├─────────────────────┤    ├─────────────────────┤                     │
│  │                     │    │                     │                     │
│  │  ┌───────────────┐  │    │  ┌───────────────┐  │                     │
│  │  │    Pipes      │  │    │  │   Mutexes &   │  │                     │
│  │  │   (unnamed)   │  │    │  │  Cond Vars    │  │                     │
│  │  └───────────────┘  │    │  └───────────────┘  │                     │
│  │         │           │    │         │           │                     │
│  │         ▼           │    │         ▼           │                     │
│  │  ┌───────────────┐  │    │  ┌───────────────┐  │                     │
│  │  │    FIFOs      │  │    │  │  Read-Write   │  │                     │
│  │  │ (named pipes) │  │    │  │    Locks      │  │                     │
│  │  └───────────────┘  │    │  └───────────────┘  │                     │
│  │         │           │    │         │           │                     │
│  │         ▼           │    │         ▼           │                     │
│  │  ┌───────────────┐  │    │  ┌───────────────┐  │                     │
│  │  │   Message     │──┼────┼──│  Semaphores   │  │                     │
│  │  │    Queues     │  │    │  │ (POSIX/SysV)  │  │                     │
│  │  │ (POSIX/SysV)  │  │    │  └───────────────┘  │                     │
│  │  └───────────────┘  │    │         │           │                     │
│  │         │           │    │         ▼           │                     │
│  │         ▼           │    │  ┌───────────────┐  │                     │
│  │  ┌───────────────┐  │    │  │    Record     │  │                     │
│  │  │Shared Memory  │◄─┼────┼──│   Locking     │  │                     │
│  │  │ (POSIX/SysV)  │  │    │  │   (fcntl)     │  │                     │
│  │  └───────────────┘  │    │  └───────────────┘  │                     │
│  │         │           │    │                     │                     │
│  └─────────┼───────────┘    └─────────────────────┘                     │
│            │                                                             │
│            ▼                                                             │
│  ┌─────────────────────┐                                                │
│  │   REMOTE PROCEDURE  │                                                │
│  │       CALLS         │                                                │
│  │  (Sun RPC + XDR)    │                                                │
│  └─────────────────────┘                                                │
│                                                                          │
└─────────────────────────────────────────────────────────────────────────┘

Unix IPC Architecture Overview

POSIX vs System V: The Two API Families

┌─────────────────────────────────────────────────────────────────────────┐
│                    POSIX vs SYSTEM V IPC                                │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                          │
│   POSIX IPC (Modern)                 System V IPC (Legacy)              │
│   ─────────────────                  ──────────────────                 │
│                                                                          │
│   ✓ Uses filesystem namespace        ✓ Uses numeric keys (ftok)         │
│   ✓ Reference counting               ✓ Kernel-persistent                │
│   ✓ Simpler API                      ✓ More features (semaphore sets)   │
│   ✓ Better portability               ✓ Widely deployed                  │
│                                                                          │
│   Message Queues:                    Message Queues:                    │
│   mq_open(), mq_send()               msgget(), msgsnd()                 │
│   mq_receive(), mq_close()           msgrcv(), msgctl()                 │
│                                                                          │
│   Semaphores:                        Semaphores:                        │
│   sem_open(), sem_wait()             semget(), semop()                  │
│   sem_post(), sem_close()            semctl()                           │
│                                                                          │
│   Shared Memory:                     Shared Memory:                     │
│   shm_open(), mmap()                 shmget(), shmat()                  │
│   shm_unlink()                       shmdt(), shmctl()                  │
│                                                                          │
└─────────────────────────────────────────────────────────────────────────┘

POSIX vs System V Comparison

Prerequisites & Background Knowledge

Before starting these projects, you should have foundational understanding in these areas:

Essential Prerequisites (Must Have)

Programming Skills:

C programming (pointers, memory management, structs)
Understanding of process creation with fork()
Basic file I/O operations (open, read, write, close)
Familiarity with errno and error handling
Recommended Reading: “The C Programming Language” by Kernighan & Ritchie

Operating Systems Fundamentals:

Process vs Thread concepts
Virtual memory basics
File descriptors
System calls vs library functions
Recommended Reading: “Operating Systems: Three Easy Pieces” by Arpaci-Dusseau — Ch. 5-6

Unix Environment:

Shell scripting basics
Reading man pages (man 2 pipe, man 7 sem_overview)
Using strace and lsof
Recommended Reading: “Advanced Programming in the UNIX Environment” by Stevens & Rago — Ch. 1-3

Helpful But Not Required

Threading:

pthreads basics (pthread_create, pthread_join)
Can learn during: Projects 7-9

Networking:

TCP/IP basics
Can learn during: Project 18 (Sun RPC)

Self-Assessment Questions

Before starting, ask yourself:

✅ Can you explain what happens when you call fork()?
✅ Do you understand file descriptors and why 0, 1, 2 are special?
✅ Can you allocate memory with malloc() and avoid leaks?
✅ Have you used strace to trace system calls?
✅ Do you know the difference between a process and a thread?

If you answered “no” to questions 1-3: Spend 2 weeks on Stevens’ APUE Ch. 1-8 before starting. If you answered “yes” to all: You’re ready to begin!

Development Environment Setup

Required Tools:

GCC or Clang (C11 support)
Linux (Ubuntu 22.04+ or similar) — macOS lacks some System V features
make for building projects
strace and ltrace for debugging

Recommended Tools:

Valgrind for memory leak detection
GDB for debugging
ipcs and ipcrm for inspecting System V IPC objects

Testing Your Setup:

# Verify POSIX IPC support
$ ls /dev/shm/
# Should list any existing shared memory objects

# Verify System V IPC support
$ ipcs
------ Message Queues --------
key        msqid      owner      perms      used-bytes   messages

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch

------ Semaphore Arrays --------
key        semid      owner      perms      nsems

# Verify compiler
$ gcc --version
gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0

# Check PIPE_BUF limit
$ getconf PIPE_BUF /
4096

Time Investment:

Foundation projects (1-4): Weekend each (4-8 hours)
Synchronization projects (5-10): 1 week each (10-20 hours)
Shared Memory projects (11-14): 1-2 weeks each (15-30 hours)
Advanced projects (15-18): 2+ weeks each (20-40 hours)
Total sprint: 4-6 months if doing all projects sequentially

Important Reality Check: IPC is notoriously tricky to debug. Deadlocks will happen. Processes will hang. You’ll leak semaphores and shared memory segments that persist after your program crashes. This is normal. The ipcs and ipcrm commands will become your best friends. Embrace the chaos—it’s how you learn.

Core Concept Analysis

1. Pipes: The Simplest IPC

Pipes are unidirectional byte streams between related processes. Created by pipe(), they return two file descriptors: one for reading, one for writing.

┌─────────────────────────────────────────────────────────────────────────┐
│                           PIPE MECHANISM                                 │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                          │
│   Parent Process                        Child Process                   │
│   ──────────────                        ─────────────                   │
│                                                                          │
│   Before fork():                                                         │
│   ┌─────────────────────────────────────────────────────────┐           │
│   │  fd[0] ──────────► KERNEL PIPE BUFFER ◄────────── fd[1] │           │
│   │  (read)            (4KB - 64KB)              (write)    │           │
│   └─────────────────────────────────────────────────────────┘           │
│                                                                          │
│   After fork():                                                          │
│   ┌──────────────┐                      ┌──────────────┐                │
│   │   PARENT     │                      │    CHILD     │                │
│   │              │                      │              │                │
│   │  fd[0] (R)   │    KERNEL BUFFER     │  fd[0] (R)   │                │
│   │  fd[1] (W) ──┼─────────────────────►│  fd[1] (W)   │                │
│   │              │     ◄───────────────┼──            │                │
│   │  close(fd[0])│                      │ close(fd[1]) │                │
│   │  write(fd[1])│                      │ read(fd[0])  │                │
│   └──────────────┘                      └──────────────┘                │
│                                                                          │
│   Key Insight: After fork, CLOSE the ends you don't need!               │
│                                                                          │
└─────────────────────────────────────────────────────────────────────────┘

Pipe Mechanism

Critical Constants:

PIPE_BUF: Writes up to this size are atomic (usually 4096 bytes)
If pipe is full, write() blocks
If pipe is empty, read() blocks
If all write ends close, read() returns 0 (EOF)
If all read ends close, write() generates SIGPIPE

2. FIFOs: Named Pipes for Unrelated Processes

FIFOs appear in the filesystem and allow communication between unrelated processes.

┌─────────────────────────────────────────────────────────────────────────┐
│                           FIFO (Named Pipe)                              │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                          │
│   $ mkfifo /tmp/myfifo                                                  │
│   $ ls -l /tmp/myfifo                                                   │
│   prw-r--r-- 1 user user 0 Jan 1 12:00 /tmp/myfifo                     │
│   ^                                                                      │
│   └── 'p' indicates pipe (FIFO)                                         │
│                                                                          │
│   ┌─────────────────┐          ┌─────────────────┐                      │
│   │  Process A      │          │  Process B      │                      │
│   │  (Writer)       │          │  (Reader)       │                      │
│   │                 │          │                 │                      │
│   │  fd = open(     │  ┌────┐  │  fd = open(     │                      │
│   │    "/tmp/myfifo"│  │FIFO│  │    "/tmp/myfifo"│                      │
│   │    O_WRONLY)    │──┤    ├──│    O_RDONLY)    │                      │
│   │                 │  └────┘  │                 │                      │
│   │  write(fd, ...) │──────────│  read(fd, ...)  │                      │
│   └─────────────────┘          └─────────────────┘                      │
│                                                                          │
│   Blocking Behavior:                                                     │
│   • open() for reading BLOCKS until a writer opens                      │
│   • open() for writing BLOCKS until a reader opens                      │
│   • Use O_NONBLOCK to avoid blocking                                    │
│                                                                          │
└─────────────────────────────────────────────────────────────────────────┘

FIFO Named Pipe

3. POSIX Message Queues

Message queues provide discrete messages with priorities, unlike the byte-stream model of pipes.

┌─────────────────────────────────────────────────────────────────────────┐
│                      POSIX MESSAGE QUEUE                                 │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                          │
│   Message Queue: /my_queue                                              │
│   ┌─────────────────────────────────────────────────────────────────┐   │
│   │  Priority 31 (Highest)                                           │   │
│   │  ┌─────────┐                                                     │   │
│   │  │ MSG 1   │ ← Dequeued first (highest priority)                │   │
│   │  └─────────┘                                                     │   │
│   │  Priority 15                                                     │   │
│   │  ┌─────────┐ ┌─────────┐                                        │   │
│   │  │ MSG 2   │ │ MSG 3   │ ← FIFO within same priority           │   │
│   │  └─────────┘ └─────────┘                                        │   │
│   │  Priority 0 (Lowest)                                             │   │
│   │  ┌─────────┐ ┌─────────┐ ┌─────────┐                            │   │
│   │  │ MSG 4   │ │ MSG 5   │ │ MSG 6   │                            │   │
│   │  └─────────┘ └─────────┘ └─────────┘                            │   │
│   └─────────────────────────────────────────────────────────────────┘   │
│                                                                          │
│   Key Functions:                                                         │
│   • mq_open("/my_queue", O_CREAT | O_RDWR, 0644, &attr)               │
│   • mq_send(mqd, buffer, len, priority)                                 │
│   • mq_receive(mqd, buffer, max_len, &priority)                        │
│   • mq_notify(mqd, &sigevent) — async notification                     │
│   • mq_getattr(mqd, &attr) / mq_setattr()                              │
│                                                                          │
│   Attributes (mq_attr):                                                  │
│   • mq_maxmsg  — max messages in queue                                  │
│   • mq_msgsize — max size of each message                               │
│   • mq_curmsgs — current number of messages                             │
│   • mq_flags   — O_NONBLOCK                                             │
│                                                                          │
└─────────────────────────────────────────────────────────────────────────┘

POSIX Message Queue

4. System V Message Queues

Older API with message types for multiplexing multiple logical channels.

┌─────────────────────────────────────────────────────────────────────────┐
│                    SYSTEM V MESSAGE QUEUE                                │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                          │
│   key_t key = ftok("/path/to/file", 'A');  // Generate unique key       │
│   int msqid = msgget(key, IPC_CREAT | 0644);                            │
│                                                                          │
│   Message Structure:                                                     │
│   struct msgbuf {                                                        │
│       long mtype;     // Message type (MUST be > 0)                     │
│       char mtext[N];  // Message data                                   │
│   };                                                                     │
│                                                                          │
│   Queue with Multiple Message Types:                                     │
│   ┌─────────────────────────────────────────────────────────────────┐   │
│   │  mtype=1 │ mtype=2 │ mtype=1 │ mtype=3 │ mtype=2 │              │   │
│   │  ┌─────┐ │ ┌─────┐ │ ┌─────┐ │ ┌─────┐ │ ┌─────┐ │              │   │
│   │  │ A   │ │ │ B   │ │ │ C   │ │ │ D   │ │ │ E   │ │              │   │
│   │  └─────┘ │ └─────┘ │ └─────┘ │ └─────┘ │ └─────┘ │              │   │
│   └─────────────────────────────────────────────────────────────────┘   │
│                                                                          │
│   Receive Modes (msgrcv msgtyp parameter):                              │
│   • msgtyp = 0  → Receive first message (any type)                      │
│   • msgtyp > 0  → Receive first message of type msgtyp                  │
│   • msgtyp < 0  → Receive first message with type ≤ |msgtyp|           │
│                                                                          │
│   Example: Client-Server Multiplexing                                   │
│   • Server receives: msgtyp = 1 (requests)                              │
│   • Client 100 receives: msgtyp = 100 (responses for client 100)        │
│   • Client 101 receives: msgtyp = 101 (responses for client 101)        │
│                                                                          │
└─────────────────────────────────────────────────────────────────────────┘

System V Message Queue

5. Mutexes and Condition Variables

The fundamental building blocks for thread synchronization.

┌─────────────────────────────────────────────────────────────────────────┐
│                 MUTEX + CONDITION VARIABLE PATTERN                       │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                          │
│   Producer-Consumer with Bounded Buffer:                                 │
│                                                                          │
│   PRODUCER                              CONSUMER                        │
│   ────────                              ────────                        │
│   pthread_mutex_lock(&mutex);           pthread_mutex_lock(&mutex);     │
│                                                                          │
│   while (count == MAX_SIZE) {           while (count == 0) {            │
│       pthread_cond_wait(                    pthread_cond_wait(          │
│           &not_full, &mutex);                   &not_empty, &mutex);    │
│   }                                     }                               │
│   // CRITICAL: while, not if!           // Handle spurious wakeups!    │
│                                                                          │
│   buffer[in] = item;                    item = buffer[out];             │
│   in = (in + 1) % MAX_SIZE;             out = (out + 1) % MAX_SIZE;     │
│   count++;                              count--;                        │
│                                                                          │
│   pthread_cond_signal(&not_empty);      pthread_cond_signal(&not_full); │
│   pthread_mutex_unlock(&mutex);         pthread_mutex_unlock(&mutex);   │
│                                                                          │
│                                                                          │
│   ┌──────────────────────────────────────────────────────────────────┐  │
│   │                         BOUNDED BUFFER                            │  │
│   │  ┌────┬────┬────┬────┬────┬────┬────┬────┐                       │  │
│   │  │    │    │ D1 │ D2 │ D3 │    │    │    │                       │  │
│   │  └────┴────┴────┴────┴────┴────┴────┴────┘                       │  │
│   │            ▲              ▲                                       │  │
│   │           out             in                                      │  │
│   │           (consumer)      (producer)                              │  │
│   └──────────────────────────────────────────────────────────────────┘  │
│                                                                          │
│   SPURIOUS WAKEUP: pthread_cond_wait() can return even when no         │
│   signal was sent. ALWAYS use while() loop, never if()!                 │
│                                                                          │
└─────────────────────────────────────────────────────────────────────────┘

Mutex and Condition Variables

6. Read-Write Locks

Optimize for read-heavy workloads where multiple readers can proceed concurrently.

┌─────────────────────────────────────────────────────────────────────────┐
│                         READ-WRITE LOCKS                                 │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                          │
│   Concurrency Matrix:                                                    │
│   ┌────────────┬─────────────┬─────────────┐                            │
│   │            │  Reader     │   Writer    │                            │
│   │            │  Holding    │   Holding   │                            │
│   ├────────────┼─────────────┼─────────────┤                            │
│   │ Reader     │     ✓       │     ✗       │                            │
│   │ Wants      │  (allowed)  │  (blocked)  │                            │
│   ├────────────┼─────────────┼─────────────┤                            │
│   │ Writer     │     ✗       │     ✗       │                            │
│   │ Wants      │  (blocked)  │  (blocked)  │                            │
│   └────────────┴─────────────┴─────────────┘                            │
│                                                                          │
│   Timeline Example:                                                      │
│   ┌─────────────────────────────────────────────────────────────────┐   │
│   │ Time:  t1    t2    t3    t4    t5    t6    t7    t8    t9       │   │
│   │        │     │     │     │     │     │     │     │     │        │   │
│   │ R1:    ├─────────────────────────────────────────┤              │   │
│   │        │     rdlock()                    unlock() │              │   │
│   │ R2:    │     ├─────────────────────┤              │              │   │
│   │        │     │  rdlock()   unlock() │              │              │   │
│   │ R3:    │     │     ├───────────────┤              │              │   │
│   │        │     │     │               │              │              │   │
│   │ W1:    │     │     │  wrlock()─────┼─────BLOCKED──┼──────────┤   │   │
│   │        │     │     │               │              │    RUNS  │   │   │
│   └─────────────────────────────────────────────────────────────────┘   │
│                                                                          │
│   Writer Starvation Problem:                                             │
│   • If readers continuously arrive, writer may wait forever             │
│   • Some implementations give preference to writers                      │
│   • pthread_rwlockattr_setkind_np() can set preference                  │
│                                                                          │
└─────────────────────────────────────────────────────────────────────────┘

Read-Write Locks

7. Record Locking (fcntl)

Lock byte ranges within files, enabling concurrent database access.

┌─────────────────────────────────────────────────────────────────────────┐
│                         RECORD LOCKING (fcntl)                           │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                          │
│   File: database.db                                                      │
│   ┌────────────────────────────────────────────────────────────────┐    │
│   │ Offset:  0      100     200     300     400     500     600    │    │
│   │          │       │       │       │       │       │       │     │    │
│   │          ├───────┴───────┴───────┴───────┴───────┴───────┤     │    │
│   │          │                   FILE DATA                    │     │    │
│   │          └────────────────────────────────────────────────┘     │    │
│   │                                                                 │    │
│   │  Process A: Write Lock [100-200)                               │    │
│   │          ├───────┤▓▓▓▓▓▓▓├───────┼───────┼───────┼───────┤     │    │
│   │                  ▲▓▓▓▓▓▓▓▲                                      │    │
│   │                  │LOCKED │                                      │    │
│   │                                                                 │    │
│   │  Process B: Read Lock [300-500)                                │    │
│   │          ├───────┼───────┼───────┤░░░░░░░░░░░░░░░├───────┤     │    │
│   │                                  ▲░░░░░░░░░░░░░░░▲              │    │
│   │                                  │  READ LOCKED  │              │    │
│   │                                                                 │    │
│   │  Process C wants: Write Lock [150-350)                         │    │
│   │          ├───────┼───XXXX├───────┼XXXX───┼───────┼───────┤     │    │
│   │                  ▲CONFLICT▲      ▲CONFLICT                      │    │
│   │                  BLOCKED!        BLOCKED!                       │    │
│   └────────────────────────────────────────────────────────────────┘    │
│                                                                          │
│   struct flock {                                                         │
│       short l_type;    // F_RDLCK, F_WRLCK, F_UNLCK                     │
│       short l_whence;  // SEEK_SET, SEEK_CUR, SEEK_END                  │
│       off_t l_start;   // Starting offset                               │
│       off_t l_len;     // Length (0 = to EOF)                           │
│       pid_t l_pid;     // PID holding lock (F_GETLK only)              │
│   };                                                                     │
│                                                                          │
│   Commands:                                                              │
│   • F_SETLK  — Try to acquire lock, return error if blocked            │
│   • F_SETLKW — Try to acquire lock, WAIT if blocked                    │
│   • F_GETLK  — Test if lock would succeed, return blocker info         │
│                                                                          │
│   Advisory vs Mandatory:                                                 │
│   • Advisory (default): Cooperative, processes can ignore locks         │
│   • Mandatory: Kernel enforces (mount -o mand, chmod g+s,g-x)          │
│                                                                          │
└─────────────────────────────────────────────────────────────────────────┘

Record Locking

8. POSIX Semaphores

Counting semaphores for resource management and synchronization.

┌─────────────────────────────────────────────────────────────────────────┐
│                        POSIX SEMAPHORES                                  │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                          │
│   Named Semaphore (persists in filesystem):                             │
│   sem_t *sem = sem_open("/my_sem", O_CREAT, 0644, initial_value);      │
│                                                                          │
│   Unnamed Semaphore (in shared memory):                                  │
│   sem_t sem;                                                             │
│   sem_init(&sem, pshared, initial_value);                               │
│   // pshared = 0: thread-shared                                         │
│   // pshared = 1: process-shared (must be in shared memory!)            │
│                                                                          │
│   Binary Semaphore (Mutex-like):                                         │
│   ┌───────────────────────────────────────────────────────────────┐     │
│   │  Value: 1                                                      │     │
│   │  ┌─────────────────────────────────────────────────────────┐  │     │
│   │  │  sem_wait()           sem_post()                        │  │     │
│   │  │      │                    ▲                             │  │     │
│   │  │      ▼                    │                             │  │     │
│   │  │  ┌───────┐            ┌───────┐                         │  │     │
│   │  │  │ 1→0   │───────────►│ 0→1   │                         │  │     │
│   │  │  │ ENTER │  CRITICAL  │ EXIT  │                         │  │     │
│   │  │  └───────┘   SECTION  └───────┘                         │  │     │
│   │  └─────────────────────────────────────────────────────────┘  │     │
│   └───────────────────────────────────────────────────────────────┘     │
│                                                                          │
│   Counting Semaphore (Resource Pool):                                    │
│   ┌───────────────────────────────────────────────────────────────┐     │
│   │  Value: 3 (3 database connections available)                   │     │
│   │                                                                 │     │
│   │  sem_wait() → 3→2  (Thread A takes connection)                 │     │
│   │  sem_wait() → 2→1  (Thread B takes connection)                 │     │
│   │  sem_wait() → 1→0  (Thread C takes connection)                 │     │
│   │  sem_wait() → BLOCKED! (Thread D waits)                        │     │
│   │  sem_post() → 0→1  (Thread A returns connection)               │     │
│   │  → Thread D unblocks, 1→0                                      │     │
│   └───────────────────────────────────────────────────────────────┘     │
│                                                                          │
│   Key Difference from Mutex:                                             │
│   • Semaphore has no "owner" — any thread can post                      │
│   • Can count beyond 1                                                   │
│   • sem_post() from signal handler is safe                              │
│                                                                          │
└─────────────────────────────────────────────────────────────────────────┘

POSIX Semaphores

9. System V Semaphores

Complex but powerful: semaphore sets with atomic multi-semaphore operations.

┌─────────────────────────────────────────────────────────────────────────┐
│                       SYSTEM V SEMAPHORES                                │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                          │
│   Semaphore Set (3 semaphores):                                         │
│   key_t key = ftok("/path", 'S');                                       │
│   int semid = semget(key, 3, IPC_CREAT | 0644);                        │
│                                                                          │
│   ┌─────────────────────────────────────────────────────────────────┐   │
│   │  semid = 12345                                                   │   │
│   │  ┌─────────────┬─────────────┬─────────────┐                    │   │
│   │  │  sem[0]     │  sem[1]     │  sem[2]     │                    │   │
│   │  │  value=5    │  value=1    │  value=0    │                    │   │
│   │  │  (resources)│  (mutex)    │  (counter)  │                    │   │
│   │  └─────────────┴─────────────┴─────────────┘                    │   │
│   └─────────────────────────────────────────────────────────────────┘   │
│                                                                          │
│   Atomic Multi-Semaphore Operation:                                      │
│   struct sembuf ops[] = {                                                │
│       { 0, -1, 0 },      // Decrement sem[0] by 1                       │
│       { 1, -1, 0 },      // Decrement sem[1] by 1                       │
│       { 2,  1, 0 },      // Increment sem[2] by 1                       │
│   };                                                                     │
│   semop(semid, ops, 3);  // ALL THREE happen atomically!                │
│                                                                          │
│   SEM_UNDO Flag (Crash Recovery):                                        │
│   struct sembuf op = { 0, -1, SEM_UNDO };                               │
│   // If process crashes, kernel automatically reverses the operation    │
│   // Kernel maintains semadj value per process per semaphore            │
│                                                                          │
│   ┌─────────────────────────────────────────────────────────────────┐   │
│   │  Process A                                                       │   │
│   │  semop(semid, {0, -1, SEM_UNDO}, 1);  // sem[0]: 5→4            │   │
│   │  semop(semid, {0, -1, SEM_UNDO}, 1);  // sem[0]: 4→3            │   │
│   │  semadj[0] = +2                                                  │   │
│   │                                                                  │   │
│   │  CRASH! 💥                                                       │   │
│   │                                                                  │   │
│   │  Kernel applies semadj: sem[0]: 3→5 (restored!)                 │   │
│   └─────────────────────────────────────────────────────────────────┘   │
│                                                                          │
│   Wait-for-Zero:                                                         │
│   struct sembuf op = { 0, 0, 0 };  // Wait until sem[0] == 0            │
│   // Useful for barrier synchronization                                  │
│                                                                          │
└─────────────────────────────────────────────────────────────────────────┘

System V Semaphores

10. POSIX Shared Memory

Map memory regions that multiple processes can access directly.

┌─────────────────────────────────────────────────────────────────────────┐
│                      POSIX SHARED MEMORY                                 │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                          │
│   Creating Shared Memory:                                                │
│   int fd = shm_open("/my_shm", O_CREAT | O_RDWR, 0644);                │
│   ftruncate(fd, SIZE);                                                   │
│   void *ptr = mmap(NULL, SIZE, PROT_READ|PROT_WRITE,                    │
│                    MAP_SHARED, fd, 0);                                   │
│                                                                          │
│   ┌─────────────────────────────────────────────────────────────────┐   │
│   │                        PHYSICAL MEMORY                           │   │
│   │   ┌──────────────────────────────────────────────────────────┐  │   │
│   │   │              SHARED MEMORY REGION                         │  │   │
│   │   │             /dev/shm/my_shm                               │  │   │
│   │   └─────────────────────────▲───────────────────────────────┘  │   │
│   │                             │                                   │   │
│   │              ┌──────────────┴──────────────┐                   │   │
│   │              │                              │                   │   │
│   │   ┌──────────▼──────────┐     ┌────────────▼────────────┐      │   │
│   │   │   PROCESS A         │     │    PROCESS B            │      │   │
│   │   │   Virtual Address   │     │    Virtual Address      │      │   │
│   │   │   Space             │     │    Space                │      │   │
│   │   │   ┌────────────┐    │     │    ┌────────────┐       │      │   │
│   │   │   │ 0x7f...    │    │     │    │ 0x7f...    │       │      │   │
│   │   │   │ mmap()     │────┼─────┼────│ mmap()     │       │      │   │
│   │   │   │ region     │    │     │    │ region     │       │      │   │
│   │   │   └────────────┘    │     │    └────────────┘       │      │   │
│   │   └─────────────────────┘     └─────────────────────────┘      │   │
│   └─────────────────────────────────────────────────────────────────┘   │
│                                                                          │
│   MAP_SHARED vs MAP_PRIVATE:                                             │
│   • MAP_SHARED: Changes visible to all processes, written to file       │
│   • MAP_PRIVATE: Copy-on-write, changes are private                     │
│                                                                          │
│   CRITICAL: Shared memory requires EXTERNAL SYNCHRONIZATION!            │
│   Use mutexes/semaphores with PTHREAD_PROCESS_SHARED attribute          │
│                                                                          │
└─────────────────────────────────────────────────────────────────────────┘

POSIX Shared Memory

11. System V Shared Memory

The older API with explicit attach/detach semantics.

┌─────────────────────────────────────────────────────────────────────────┐
│                     SYSTEM V SHARED MEMORY                               │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                          │
│   key_t key = ftok("/path", 'M');                                       │
│   int shmid = shmget(key, SIZE, IPC_CREAT | 0644);                     │
│   void *ptr = shmat(shmid, NULL, 0);  // Attach                        │
│   // ... use shared memory ...                                          │
│   shmdt(ptr);                          // Detach                        │
│   shmctl(shmid, IPC_RMID, NULL);       // Mark for deletion             │
│                                                                          │
│   ┌─────────────────────────────────────────────────────────────────┐   │
│   │  shmget() creates segment in kernel                              │   │
│   │  ┌─────────────────────────────────────────────────────────────┐│   │
│   │  │  Kernel Shared Memory Table                                  ││   │
│   │  │  ┌──────┬───────┬───────┬───────┬─────────────────────────┐││   │
│   │  │  │shmid │ key   │ size  │nattch │ permissions             │││   │
│   │  │  ├──────┼───────┼───────┼───────┼─────────────────────────┤││   │
│   │  │  │ 100  │0x1234 │ 4096  │   2   │ rw-r--r--               │││   │
│   │  │  │ 101  │0x5678 │ 8192  │   1   │ rw-------               │││   │
│   │  │  └──────┴───────┴───────┴───────┴─────────────────────────┘││   │
│   │  └─────────────────────────────────────────────────────────────┘│   │
│   │                                                                  │   │
│   │  shmat() maps to process address space                          │   │
│   │  ┌────────────────────┐      ┌────────────────────┐             │   │
│   │  │  Process A         │      │  Process B         │             │   │
│   │  │  nattch++          │      │  nattch++          │             │   │
│   │  │  0x7fff0000 ───────┼──────┼──▶ shmid=100       │             │   │
│   │  └────────────────────┘      └────────────────────┘             │   │
│   │                                                                  │   │
│   │  shmctl(IPC_RMID) marks for deletion                            │   │
│   │  • Segment deleted when nattch reaches 0                        │   │
│   │  • Survives process exit if nattch > 0                          │   │
│   └─────────────────────────────────────────────────────────────────┘   │
│                                                                          │
│   Attachment Address:                                                    │
│   • NULL: Kernel chooses address                                         │
│   • Specific address: shmat(shmid, addr, SHM_RND)                       │
│   • SHM_RDONLY: Attach read-only                                        │
│                                                                          │
└─────────────────────────────────────────────────────────────────────────┘

System V Shared Memory

12. Sun RPC (Remote Procedure Calls)

Make function calls across network boundaries transparently.

┌─────────────────────────────────────────────────────────────────────────┐
│                          SUN RPC ARCHITECTURE                            │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                          │
│   ┌─────────────────────────────────────────────────────────────────┐   │
│   │                         RPC FLOW                                 │   │
│   │                                                                  │   │
│   │   CLIENT                                SERVER                   │   │
│   │   ──────                                ──────                   │   │
│   │   ┌─────────────────┐                  ┌─────────────────┐      │   │
│   │   │  Application    │                  │  Application    │      │   │
│   │   │  result = add(a,b)                 │  int add(a,b) { │      │   │
│   │   └────────┬────────┘                  │    return a+b;  │      │   │
│   │            │                           │  }               │      │   │
│   │            ▼                           └────────▲────────┘      │   │
│   │   ┌─────────────────┐                  ┌────────┴────────┐      │   │
│   │   │  Client Stub    │                  │  Server Stub    │      │   │
│   │   │  (generated by  │                  │  (generated by  │      │   │
│   │   │   rpcgen)       │                  │   rpcgen)       │      │   │
│   │   └────────┬────────┘                  └────────▲────────┘      │   │
│   │            │ XDR encode                         │ XDR decode    │   │
│   │            ▼                                    │               │   │
│   │   ┌─────────────────┐                  ┌────────┴────────┐      │   │
│   │   │   RPC Runtime   │                  │   RPC Runtime   │      │   │
│   │   └────────┬────────┘                  └────────▲────────┘      │   │
│   │            │                                    │               │   │
│   │            ▼ ═══════════ NETWORK ═══════════════╝               │   │
│   │                                                                  │   │
│   └─────────────────────────────────────────────────────────────────┘   │
│                                                                          │
│   rpcgen Workflow:                                                       │
│   ┌─────────────────────────────────────────────────────────────────┐   │
│   │  calc.x (Interface Definition)                                   │   │
│   │  ─────────────────────────────                                   │   │
│   │  program CALC_PROG {                                             │   │
│   │      version CALC_VERS {                                         │   │
│   │          int ADD(operands) = 1;                                  │   │
│   │          int SUB(operands) = 2;                                  │   │
│   │      } = 1;                                                      │   │
│   │  } = 0x20000001;                                                 │   │
│   │                                                                  │   │
│   │  $ rpcgen calc.x                                                 │   │
│   │  ↓                                                               │   │
│   │  calc.h        - Common definitions                              │   │
│   │  calc_clnt.c   - Client stub                                     │   │
│   │  calc_svc.c    - Server main + dispatch                          │   │
│   │  calc_xdr.c    - XDR serialization routines                      │   │
│   └─────────────────────────────────────────────────────────────────┘   │
│                                                                          │
│   Port Mapper (rpcbind):                                                 │
│   • Server registers: program number + version → port                   │
│   • Client queries: "Where is CALC_PROG version 1?"                    │
│   • Response: "Port 45678"                                              │
│   • Client connects directly to port 45678                              │
│                                                                          │
│   XDR (External Data Representation):                                    │
│   • Big-endian, 4-byte aligned                                          │
│   • Handles int, float, string, arrays, structs                         │
│   • Machine-independent wire format                                      │
│                                                                          │
└─────────────────────────────────────────────────────────────────────────┘

Sun RPC Architecture

Concept Summary Table

This section provides a map of the mental models you will build during these projects.

Concept Cluster	What You Need to Internalize
Pipes & FIFOs	Unidirectional byte streams. Parent-child inheritance. PIPE_BUF atomicity. EOF on close.
Message Queues	Discrete messages vs byte streams. POSIX priorities vs System V types. Kernel persistence.
Mutexes & Condvars	Protect shared data, signal state changes. ALWAYS use while() not if() for conditions.
Read-Write Locks	Multiple readers OR one writer. Trade-off between concurrency and fairness.
Record Locking	Byte-range locks within files. Advisory vs mandatory. Deadlock detection.
Semaphores	Counting resources, not just locking. POSIX simplicity vs System V atomic sets. SEM_UNDO recovery.
Shared Memory	Fastest IPC but requires external synchronization. POSIX mmap vs System V attach.
Sun RPC	Transparently call functions across network. rpcgen for stubs, XDR for serialization.

Deep Dive Reading by Concept

This section maps each concept to specific book chapters for deeper understanding.

Pipes & Basic IPC

Concept	Book & Chapter	Why This Matters
Pipe fundamentals	“Advanced Programming in the UNIX Environment” by Stevens & Rago — Ch. 15	Canonical explanation of pipe semantics and limitations
FIFO implementation	“The Linux Programming Interface” by Kerrisk — Ch. 44	Modern Linux-specific details and edge cases
Shell pipelines	“The Linux Command Line” by Shotts — Ch. 6	Understanding how the shell uses pipes

Message Queues

Concept	Book & Chapter	Why This Matters
POSIX message queues	“The Linux Programming Interface” by Kerrisk — Ch. 52	Complete POSIX MQ coverage with examples
System V message queues	“Advanced Programming in the UNIX Environment” by Stevens & Rago — Ch. 15.7	Classic treatment with design rationale

Synchronization Primitives

Concept	Book & Chapter	Why This Matters
Mutexes & Condvars	“Programming with POSIX Threads” by Butenhof — Ch. 3	The definitive pthreads reference
Deadlock avoidance	“Operating Systems: Three Easy Pieces” by Arpaci-Dusseau — Ch. 32	Theoretical foundation for deadlock
Semaphore theory	“Operating Systems: Three Easy Pieces” by Arpaci-Dusseau — Ch. 31	Dijkstra’s semaphores explained clearly

Shared Memory

Concept	Book & Chapter	Why This Matters
mmap fundamentals	“The Linux Programming Interface” by Kerrisk — Ch. 49	Memory mapping in depth
POSIX shared memory	“The Linux Programming Interface” by Kerrisk — Ch. 54	Modern shared memory API
System V shared memory	“Advanced Programming in the UNIX Environment” by Stevens & Rago — Ch. 15.9	Classic shm* API

Remote Procedure Calls

Concept	Book & Chapter	Why This Matters
RPC concepts	“Distributed Systems” by Tanenbaum — Ch. 4	Theoretical RPC foundation
XDR serialization	“Unix Network Programming Vol 2” by Stevens — Ch. 16	Wire format details

Quick Start: Your First 48 Hours

Feeling overwhelmed? Start here instead of reading everything:

Day 1 (4 hours):

Read only the “Pipes” section in Core Concepts above
Open a terminal and run: echo "hello" | cat — you just used a pipe!
Start Project 1 - write a simple program that creates a pipe and forks
Don’t worry about FIFOs or message queues yet

Day 2 (4 hours):

Add error handling to your Project 1 code
Experiment with closing/not closing pipe ends
See what happens when you write more than PIPE_BUF bytes
Read “The Core Question You’re Answering” for Project 1

End of Weekend: You now understand that pipes are kernel-buffered byte streams connecting related processes. You can explain “why does ls | grep foo work?” to someone. That’s 80% of the pipe mental model.

Next Steps:

If it clicked: Continue to Project 2 (FIFOs)
If confused: Re-read man pages (man 2 pipe, man 7 pipe)
If frustrated: Take a break! IPC is hard. Read Kerrisk Ch. 44 slowly.

Recommended Learning Path

Path 1: The Systems Programmer (Recommended Start)

Best for: Those who want a solid foundation in all IPC mechanisms

Start with Projects 1-3 (Pipes, FIFOs, popen) - Build intuition for byte streams
Then Projects 4-6 (Message Queues) - Understand discrete messages
Then Projects 7-9 (Synchronization) - Master locking primitives
Then Projects 10-14 (Shared Memory) - The fastest IPC
Finally Projects 15-18 (RPC) - Cross-network IPC

Path 2: The Performance Engineer

Best for: Those optimizing high-throughput systems

Start with Projects 10-12 (Shared Memory) - Skip to the fastest mechanism
Then Projects 7-9 (Semaphores) - Synchronize shared memory
Then Project 13 (Lock-free) - Eliminate synchronization overhead
Back to Projects 1-6 (Pipes/MQ) - Understand simpler alternatives

Path 3: The Completionist

Best for: Those building a complete IPC reference implementation

Phase 1: Data Transfer (Weeks 1-3)

Projects 1-6 (All pipe and message queue variants)

Phase 2: Synchronization (Weeks 4-6)

Projects 7-10 (All locking mechanisms)

Phase 3: Shared Memory (Weeks 7-9)

Projects 11-14 (POSIX and System V)

Phase 4: Remote IPC (Weeks 10-12)

Projects 15-18 (Sun RPC complete)

Project List

The following projects guide you from basic pipes to complete RPC systems, covering every IPC mechanism from Stevens’ book.

Project 1: Build a Shell Pipeline Executor

File: P01-shell-pipeline.md
Main Programming Language: C
Alternative Programming Languages: Rust, Go
Coolness Level: Level 3 (Genuinely Clever)
Business Potential: Level 1 (Resume Gold)
Difficulty: Level 2 (Intermediate)
Knowledge Area: Operating Systems, Process Management
Software or Tool: None (pure syscalls)
Main Book: “Advanced Programming in the UNIX Environment” by Stevens & Rago

What you’ll build: A program that executes cmd1 | cmd2 | cmd3 by creating pipes and forking processes, just like a real shell.

Why it teaches IPC: Forces you to understand pipe file descriptor inheritance across fork(), the critical importance of closing unused ends, and how EOF propagates through a pipeline.

Core challenges you’ll face:

File descriptor management → Understanding dup2() and close()
Process coordination → Multiple fork() calls, parent waiting for children
EOF handling → Why closing write ends matters

Real World Outcome

When complete, you’ll have a program that can execute arbitrary shell pipelines:

What you will see:

Working pipeline execution: Your program runs ls -la | grep txt | wc -l
Correct output: Same result as typing it in bash
Proper cleanup: No zombie processes, no leaked file descriptors

Command Line Outcome Example:

# 1. Compile your pipeline executor
$ gcc -o mypipe mypipe.c
# No errors

# 2. Run a simple two-command pipeline
$ ./mypipe "ls -la" "grep txt"
-rw-r--r-- 1 user user  1234 Jan  1 12:00 notes.txt
-rw-r--r-- 1 user user  5678 Jan  1 12:00 data.txt

# 3. TEST: Three-command pipeline
$ ./mypipe "cat /etc/passwd" "grep root" "cut -d: -f1"
root
# Output shows only "root" - data flowed through all three commands

# 4. TEST: Verify no file descriptor leaks
$ ./mypipe "ls" "cat" &
$ ls -la /proc/$!/fd
total 0
lrwx------ 1 user user 64 Jan  1 12:00 0 -> /dev/pts/0
lrwx------ 1 user user 64 Jan  1 12:00 1 -> /dev/pts/0
lrwx------ 1 user user 64 Jan  1 12:00 2 -> /dev/pts/0
# Only 0,1,2 - no leaked pipe fds!

# 5. TEST: Verify no zombie processes
$ ./mypipe "sleep 1" "cat"
$ ps aux | grep defunct
# No output - no zombies

The Core Question You’re Answering

“How does ls | grep foo | wc -l actually work at the system call level?”

Before you write any code, trace this on paper: the shell calls pipe() twice, fork() three times, and uses dup2() to rewire stdin/stdout. Each process inherits all file descriptors, but must close the ones it doesn’t use. If you don’t close the write end of a pipe, the reader never gets EOF.

Concepts You Must Understand First

Stop and research these before coding:

File Descriptor Inheritance
- What file descriptors does a child inherit after fork()?
- Why does closing fd in parent not affect child?
- Book Reference: “APUE” Ch. 3 - Stevens & Rago
dup2() System Call
- How does dup2(oldfd, newfd) work?
- What happens to newfd if it was already open?
- Book Reference: “APUE” Ch. 3.12 - Stevens & Rago
Pipe Capacity and Blocking
- What is PIPE_BUF on your system?
- When does write() to a pipe block?
- Book Reference: “The Linux Programming Interface” Ch. 44 - Kerrisk

Questions to Guide Your Design

Before implementing, think through these:

Pipe Creation Order
- Create all pipes before any fork, or one at a time?
- How do you track which pipe connects which processes?
File Descriptor Cleanup
- Which process closes which ends of which pipes?
- What happens if you forget to close the write end?
Error Handling
- What if exec() fails?
- What if pipe() fails partway through?

Thinking Exercise

Trace the File Descriptors

Before coding, draw the file descriptor table for this pipeline: A | B | C

After pipe(p1), pipe(p2), before any fork:
Parent FD table:
  3 → p1[0] (read end of pipe 1)
  4 → p1[1] (write end of pipe 1)
  5 → p2[0] (read end of pipe 2)
  6 → p2[1] (write end of pipe 2)

After forking child A:
  Child A needs: stdin=p1[0]? No wait... A writes TO pipe.
  Actually, A's stdout should go to p1[1].

  [Continue this trace for all processes...]

Questions while tracing:

Which fds does process A close after dup2?
What would happen if B doesn’t close p1[1]?
When does A’s write() return EOF?

The Interview Questions They’ll Ask

Prepare to answer these:

“Walk me through what happens when you type ls | grep foo in a shell.”
“Why is it important to close unused pipe file descriptors?”
“What’s the difference between pipe() and pipe2() on Linux?”
“How would you implement a pipeline with error propagation (pipefail)?”
“What happens if a process in the middle of a pipeline dies?”

Hints in Layers

Hint 1: Start Simple First, make a TWO command pipeline work. Ignore three+ commands until two works perfectly.

Hint 2: The Pattern For A | B: Create one pipe. Fork twice. Child A: dup2(pipe_write, STDOUT), close both ends, exec. Child B: dup2(pipe_read, STDIN), close both ends, exec. Parent: close both ends, wait for both children.

Hint 3: Generalizing

// Pseudocode for N commands
create N-1 pipes
for i in 0..N:
    fork child i
    in child:
        if i > 0:
            dup2(pipe[i-1].read, STDIN)
        if i < N-1:
            dup2(pipe[i].write, STDOUT)
        close ALL pipe fds (very important!)
        exec(command[i])
parent: close all pipe fds, wait for all children

Hint 4: Debugging Use strace -f ./mypipe "ls" "cat" to see all syscalls across all processes. Look for unclosed fds or blocking reads.

Books That Will Help

Topic	Book	Chapter
Pipe semantics	“Advanced Programming in the UNIX Environment” by Stevens & Rago	Ch. 15.2
Process creation	“Operating Systems: Three Easy Pieces” by Arpaci-Dusseau	Ch. 5
File descriptors	“The Linux Programming Interface” by Kerrisk	Ch. 5

Common Pitfalls & Debugging

Problem 1: “Pipeline hangs forever”

Why: The read end is waiting for EOF, but some process still has the write end open.
Fix: Make sure EVERY process closes EVERY pipe fd it doesn’t need, BEFORE exec.
Quick test: ls -la /proc/$(pgrep yourprogram)/fd - should only show 0,1,2

Problem 2: “Broken pipe error”

Why: Writer tried to write after reader closed its end.
Fix: Usually means reader died unexpectedly. Check your exec() error handling.
Debug: Add signal handler for SIGPIPE to see where it happens.

Problem 3: “Zombie processes remain”

Why: Parent isn’t calling wait() or waitpid() for each child.
Fix: Parent must wait for ALL children after closing its pipe fds.
Quick test: ps aux | grep defunct should show nothing

Testing Your Pipeline:

# Compare your output to bash
$ ./mypipe "ls" "wc -l"
$ ls | wc -l
# Should be identical

# Test with large data
$ ./mypipe "seq 1 1000000" "wc -l"
1000000
# Should not deadlock

Project 2: Client-Server with Named Pipes (FIFOs)

File: P02-fifo-client-server.md
Main Programming Language: C
Alternative Programming Languages: Rust, Python
Coolness Level: Level 3 (Genuinely Clever)
Business Potential: Level 2 (Micro-SaaS potential)
Difficulty: Level 2 (Intermediate)
Knowledge Area: IPC, Client-Server Architecture
Software or Tool: None (pure syscalls)
Main Book: “The Linux Programming Interface” by Michael Kerrisk

What you’ll build: A simple calculator server that listens on a well-known FIFO, receives requests from multiple clients, and sends responses back through client-specific FIFOs.

Why it teaches IPC: FIFOs allow unrelated processes to communicate. This project teaches the common pattern of one well-known server FIFO plus per-client response FIFOs.

Core challenges you’ll face:

Blocking behavior → open() blocks until both ends connected
Atomic writes → Keeping requests from multiple clients separate
Cleanup → Removing FIFOs on shutdown

Real World Outcome

What you will see:

Server running: Waiting for connections on /tmp/calc_server
Multiple clients: Each creates its own response FIFO
Concurrent requests: Clients don’t interfere with each other

Command Line Outcome Example:

# Terminal 1: Start server
$ ./calc_server
Server listening on /tmp/calc_server...
Received: 5 + 3 from client 12345
Sending response: 8 to /tmp/calc_client_12345
Received: 10 * 4 from client 12346
Sending response: 40 to /tmp/calc_client_12346

# Terminal 2: Client 1
$ ./calc_client "5 + 3"
Result: 8

# Terminal 3: Client 2 (simultaneously)
$ ./calc_client "10 * 4"
Result: 40

# Verify FIFOs exist
$ ls -la /tmp/calc*
prw-r--r-- 1 user user 0 Jan  1 12:00 /tmp/calc_server
prw-r--r-- 1 user user 0 Jan  1 12:00 /tmp/calc_client_12345
prw-r--r-- 1 user user 0 Jan  1 12:00 /tmp/calc_client_12346

# After clients exit, their FIFOs are cleaned up
$ ls -la /tmp/calc_client*
ls: cannot access '/tmp/calc_client*': No such file or directory

The Core Question You’re Answering

“How can unrelated processes communicate when they can’t share file descriptors through fork()?”

Named pipes (FIFOs) live in the filesystem, so any process can open them by path. The challenge is the bidirectional communication pattern: server needs to know where to send the response. The standard solution is client-specific response FIFOs.

Concepts You Must Understand First

Stop and research these before coding:

FIFO Creation and Permissions
- What does mkfifo() do? What’s the mode parameter?
- What happens if FIFO already exists?
- Book Reference: “The Linux Programming Interface” Ch. 44.7 - Kerrisk
Blocking Semantics
- When does open() on a FIFO block?
- What’s O_NONBLOCK behavior for FIFOs?
- Book Reference: “APUE” Ch. 15.5 - Stevens & Rago
Atomic Writes
- What happens if two clients write simultaneously?
- What’s PIPE_BUF and why does it matter for FIFOs?

Hints in Layers

Hint 1: The Protocol Client sends: "pid:operation\n" (e.g., “12345:5 + 3\n”). Server extracts pid, computes, responds to /tmp/calc_client_<pid>.

Hint 2: FIFO Lifecycle Server: mkfifo(“/tmp/calc_server”), open(O_RDONLY), read loop. Client: mkfifo(“/tmp/calc_client_PID”), open server FIFO O_WRONLY, write request, open client FIFO O_RDONLY, read response, unlink client FIFO.

Hint 3: Handling EOF When all writers close, read() returns 0. Server should re-open or use O_RDWR trick to prevent EOF.

Books That Will Help

Topic	Book	Chapter
FIFO details	“The Linux Programming Interface” by Kerrisk	Ch. 44
Client-server patterns	“Unix Network Programming Vol 2” by Stevens	Ch. 4
Atomic I/O	“APUE” by Stevens & Rago	Ch. 3.11

Project 3: Implement popen() and pclose()

File: P03-implement-popen.md
Main Programming Language: C
Coolness Level: Level 4 (Hardcore Tech Flex)
Business Potential: Level 1 (Resume Gold)
Difficulty: Level 3 (Advanced)
Knowledge Area: Library Implementation, Process Management

What you’ll build: Your own implementation of the popen() and pclose() library functions.

Why it teaches IPC: popen() combines pipe(), fork(), dup2(), and exec() into a convenient API. Building it yourself ensures you understand all the pieces.

Core challenges you’ll face:

Bidirectional limitation → Why popen is read OR write, not both
Process tracking → Mapping FILE* to child pid for pclose()
Signal handling → What happens if child ignores SIGPIPE?

Real World Outcome

# Your implementation passes the same tests as the real popen
$ ./test_mypopen
Testing mypopen("ls", "r")...
  Read: file1.txt\nfile2.txt\n
  mypclose returned: 0
  PASS

Testing mypopen("cat", "w")...
  Wrote: "Hello from parent\n"
  mypclose returned: 0
  PASS

Testing mypopen("exit 42", "r")...
  mypclose returned: 42
  PASS (exit status preserved)

The Core Question You’re Answering

“Why does popen() only support reading OR writing, not both?”

Think about it: with a single pipe, data flows one direction. For bidirectional communication, you’d need two pipes and careful coordination to avoid deadlock. popen() is a convenience function for simple cases.

Project 4: POSIX Message Queue Priority Dispatcher

File: P04-posix-mq-dispatcher.md
Main Programming Language: C
Alternative Programming Languages: Rust
Coolness Level: Level 3 (Genuinely Clever)
Business Potential: Level 3 (Service & Support Model)
Difficulty: Level 3 (Advanced)
Knowledge Area: IPC, Task Scheduling

What you’ll build: A job dispatcher that uses POSIX message queue priorities to ensure high-priority jobs are processed first.

Why it teaches IPC: Unlike pipes, message queues preserve message boundaries and support priorities. This project makes those features essential.

Core challenges you’ll face:

Priority inversion → Low-priority jobs starving
Queue full handling → What to do when mq_send blocks
Async notification → Using mq_notify for efficiency

Real World Outcome

# Start the dispatcher
$ ./job_dispatcher &
Dispatcher running, queue: /job_queue

# Submit jobs with different priorities
$ ./submit_job --priority=0 --cmd="sleep 10"  # Low priority
Job 1 queued (priority 0)

$ ./submit_job --priority=31 --cmd="echo URGENT"  # High priority
Job 2 queued (priority 31)

$ ./submit_job --priority=15 --cmd="date"  # Medium priority
Job 3 queued (priority 15)

# Watch dispatcher output - processes high priority first!
Dispatcher: Processing job 2 (priority 31): echo URGENT
URGENT
Dispatcher: Processing job 3 (priority 15): date
Sat Jan  1 12:00:00 UTC 2025
Dispatcher: Processing job 1 (priority 0): sleep 10
(10 seconds later...)

Concepts You Must Understand First

mq_attr Structure
- mq_maxmsg: How many messages can queue hold?
- mq_msgsize: Maximum size of each message?
- Book Reference: “The Linux Programming Interface” Ch. 52 - Kerrisk
Priority Ordering
- Higher priority = dequeued first
- FIFO within same priority level
mq_notify for Async
- Notify via signal or thread when message arrives
- One-shot: must re-register after each notification

Project 5: System V Message Queue Multi-Client Server

File: P05-sysv-mq-server.md
Main Programming Language: C
Coolness Level: Level 3 (Genuinely Clever)
Business Potential: Level 2 (Micro-SaaS)
Difficulty: Level 3 (Advanced)
Knowledge Area: IPC, Multiplexing

What you’ll build: A server using System V message queues where clients multiplex on a single queue using message types.

Why it teaches IPC: System V message types allow selective receives (msgtyp parameter), enabling multiple logical channels on one queue.

Core challenges you’ll face:

ftok collisions → Understanding key generation
Message type protocol → Designing the multiplexing scheme
Cleanup on crash → Orphaned queues persist!

Real World Outcome

# Server uses one queue for all clients
$ ./sysv_server
Server starting, key=0x12345678, msqid=100
Waiting for requests (msgtyp=1)...

# Client 1 (PID 5001) sends request
$ ./sysv_client "HELLO"
Sending to server (msgtyp=1)
Waiting for response (msgtyp=5001)
Response: HELLO_PROCESSED

# Client 2 (PID 5002) sends simultaneously
$ ./sysv_client "WORLD"
Response: WORLD_PROCESSED

# Both used the SAME queue, but different message types!
$ ipcs -q
------ Message Queues --------
key        msqid      owner      perms      used-bytes   messages
0x12345678 100        user       644        0            0

The Core Question You’re Answering

“How can multiple clients share a single message queue without mixing up their responses?”

Message types are the key. Server receives msgtyp=1 (requests). Each client sends its PID in the request, and server responds with msgtyp=. Clients receive only their own responses.

Project 6: Message Queue Performance Benchmark

File: P06-mq-benchmark.md
Main Programming Language: C
Coolness Level: Level 2 (Practical but Forgettable)
Business Potential: Level 1 (Resume Gold)
Difficulty: Level 2 (Intermediate)
Knowledge Area: Performance Analysis, IPC

What you’ll build: A benchmark comparing POSIX vs System V message queues, pipes, and Unix domain sockets.

Why it teaches IPC: Numbers don’t lie. You’ll see exactly when each mechanism shines.

Real World Outcome

$ ./ipc_benchmark --msg-size=1024 --iterations=100000

IPC Mechanism Benchmark (1KB messages, 100K iterations)
═══════════════════════════════════════════════════════

Mechanism              Throughput     Latency (avg)   Latency (p99)
─────────────────────────────────────────────────────────────────────
Pipe                   1.2 GB/s       0.8 μs          2.1 μs
FIFO                   1.1 GB/s       0.9 μs          2.4 μs
Unix Domain Socket     1.4 GB/s       0.7 μs          1.8 μs
POSIX Message Queue    0.8 GB/s       1.2 μs          3.5 μs
System V Message Queue 0.6 GB/s       1.6 μs          4.2 μs
Shared Memory + Sem    2.8 GB/s       0.3 μs          0.8 μs

Winner: Shared Memory (for raw throughput)
Best simplicity: Unix Domain Socket

Project 7: Producer-Consumer with Mutexes and Condition Variables

File: P07-producer-consumer.md
Main Programming Language: C
Alternative Programming Languages: Rust, C++
Coolness Level: Level 3 (Genuinely Clever)
Business Potential: Level 1 (Resume Gold)
Difficulty: Level 3 (Advanced)
Knowledge Area: Concurrency, Synchronization

What you’ll build: The classic bounded-buffer producer-consumer with multiple producers and consumers using pthreads.

Why it teaches IPC: This is THE canonical synchronization problem. If you can implement this correctly, you understand mutexes and condition variables.

Core challenges you’ll face:

Spurious wakeups → Why while() not if()
Broadcast vs Signal → When to use each
Deadlock potential → Lock ordering matters

Real World Outcome

$ ./producer_consumer --producers=3 --consumers=2 --buffer-size=10 --items=1000

Producer-Consumer Simulation
Buffer size: 10, Producers: 3, Consumers: 2, Items: 1000

[P1] Produced item 1
[P2] Produced item 2
[C1] Consumed item 1
[P3] Produced item 3
[P1] Produced item 4
[C2] Consumed item 2
...
[C1] Consumed item 1000

Statistics:
  Total produced: 1000
  Total consumed: 1000
  Buffer empty waits: 234
  Buffer full waits: 156

PASS: All items produced and consumed correctly

The Core Question You’re Answering

“Why must you ALWAYS use while() instead of if() when checking conditions after pthread_cond_wait()?”

Spurious wakeups. The POSIX specification explicitly allows pthread_cond_wait() to return even when no signal was sent. Production code that uses if instead of while will eventually fail.

Project 8: Reader-Writer Lock Implementation

File: P08-rwlock-impl.md
Main Programming Language: C
Coolness Level: Level 4 (Hardcore Tech Flex)
Business Potential: Level 1 (Resume Gold)
Difficulty: Level 4 (Expert)
Knowledge Area: Concurrency, Lock Design

What you’ll build: Your own read-write lock implementation using only mutexes and condition variables.

Why it teaches IPC: Implementing rwlock from primitives reveals the design decisions: reader preference vs writer preference, and the starvation trade-offs.

Core challenges you’ll face:

Writer starvation → Continuous readers block writers forever
Reader starvation → Giving writers priority starves readers
Fair queuing → FIFO ordering is complex

Real World Outcome

$ ./test_myrwlock --readers=10 --writers=3 --duration=10s

My RWLock Test (10 readers, 3 writers, 10 seconds)

Reader 1 acquired read lock (0 writers waiting)
Reader 2 acquired read lock (0 writers waiting)
Reader 3 acquired read lock (0 writers waiting)
Writer 1 waiting... (3 readers active)
Reader 1 released read lock
Reader 2 released read lock
Reader 3 released read lock
Writer 1 acquired write lock
Writer 1 released write lock
Reader 4 acquired read lock
...

Statistics:
  Read operations: 15,234
  Write operations: 456
  Max reader wait: 12ms
  Max writer wait: 45ms
  No starvation detected: PASS

Project 9: Record Locking Database

File: P09-record-locking-db.md
Main Programming Language: C
Coolness Level: Level 3 (Genuinely Clever)
Business Potential: Level 2 (Micro-SaaS)
Difficulty: Level 3 (Advanced)
Knowledge Area: File Systems, Databases

What you’ll build: A simple key-value store where concurrent processes can read and write records using fcntl byte-range locks.

Why it teaches IPC: Record locking is how databases allow concurrent access. You’ll implement fine-grained locking on a shared file.

Core challenges you’ll face:

Deadlock detection → fcntl with F_SETLKW can deadlock
Lock inheritance → What happens across fork()?
Advisory nature → Uncooperative processes can ignore locks

Real World Outcome

# Start multiple concurrent clients
$ ./kvstore set key1 value1 &
$ ./kvstore set key2 value2 &
$ ./kvstore get key1 &
$ ./kvstore set key1 updated &

# All complete without corruption
$ ./kvstore get key1
updated
$ ./kvstore get key2
value2

# Verify locking works
$ ./kvstore lock-test key1
Process 1: Acquired write lock on key1
Process 2: Waiting for lock...
(Process 1 holds lock for 2 seconds)
Process 1: Released lock
Process 2: Acquired write lock on key1

Project 10: POSIX Semaphore Connection Pool

File: P10-semaphore-pool.md
Main Programming Language: C
Coolness Level: Level 3 (Genuinely Clever)
Business Potential: Level 3 (Service & Support)
Difficulty: Level 3 (Advanced)
Knowledge Area: Resource Management, Concurrency

What you’ll build: A database connection pool manager using POSIX counting semaphores to limit concurrent connections.

Why it teaches IPC: Counting semaphores are perfect for resource pools. The semaphore value represents available resources.

Core challenges you’ll face:

sem_timedwait → Handling connection timeout
Process-shared semaphores → Allocating in shared memory
Cleanup on crash → Returning connections when process dies

Real World Outcome

$ ./pool_manager --max-connections=5 &
Pool manager started (5 connections available)

# Spawn 10 workers, each needs a connection
$ for i in {1..10}; do ./worker $i & done

Worker 1: Acquired connection (4 remaining)
Worker 2: Acquired connection (3 remaining)
Worker 3: Acquired connection (2 remaining)
Worker 4: Acquired connection (1 remaining)
Worker 5: Acquired connection (0 remaining)
Worker 6: Waiting for connection...
Worker 7: Waiting for connection...
Worker 1: Released connection (1 remaining)
Worker 6: Acquired connection (0 remaining)
...

All workers completed successfully

Project 11: System V Semaphore Barrier

File: P11-sysv-barrier.md
Main Programming Language: C
Coolness Level: Level 3 (Genuinely Clever)
Business Potential: Level 1 (Resume Gold)
Difficulty: Level 3 (Advanced)
Knowledge Area: Parallel Computing, Synchronization

What you’ll build: A barrier synchronization primitive using System V semaphores where N processes wait until all arrive.

Why it teaches IPC: System V semaphores can atomically operate on multiple semaphores, enabling complex synchronization patterns.

Core challenges you’ll face:

Atomic multi-semaphore ops → Using semop with multiple sembuf
SEM_UNDO → Handling process crashes mid-barrier
Reusable barrier → Resetting for the next round

Real World Outcome

$ ./barrier_test --processes=5 --iterations=3

Barrier Test (5 processes, 3 iterations)

[P1] Reached barrier 1
[P3] Reached barrier 1
[P2] Reached barrier 1
[P5] Reached barrier 1
[P4] Reached barrier 1
--- All processes passed barrier 1 ---

[P2] Reached barrier 2
[P1] Reached barrier 2
[P4] Reached barrier 2
[P3] Reached barrier 2
[P5] Reached barrier 2
--- All processes passed barrier 2 ---

[P1] Reached barrier 3
[P5] Reached barrier 3
[P3] Reached barrier 3
[P4] Reached barrier 3
[P2] Reached barrier 3
--- All processes passed barrier 3 ---

All processes synchronized correctly. PASS

Project 12: POSIX Shared Memory Ring Buffer

File: P12-shm-ringbuffer.md
Main Programming Language: C
Alternative Programming Languages: Rust
Coolness Level: Level 4 (Hardcore Tech Flex)
Business Potential: Level 4 (Open Core Infrastructure)
Difficulty: Level 4 (Expert)
Knowledge Area: High-Performance IPC, Lock-Free

What you’ll build: A high-performance ring buffer in POSIX shared memory for producer-consumer communication between processes.

Why it teaches IPC: Shared memory is the fastest IPC, but requires careful synchronization. A ring buffer with proper memory barriers is a production pattern.

Core challenges you’ll face:

Memory mapping → shm_open, ftruncate, mmap
Synchronization → Semaphores in shared memory
Cache coherency → Memory barriers and atomics

Real World Outcome

$ ./shm_ringbuffer_bench --buffer-size=1MB --iterations=10M

Shared Memory Ring Buffer Benchmark
Buffer: 1MB, Messages: 10 million

Producer: Writing 10M messages...
Consumer: Reading 10M messages...

Results:
  Throughput: 8.5 million msg/sec
  Bandwidth: 8.5 GB/sec
  Latency (avg): 0.12 μs
  Latency (p99): 0.35 μs
  Zero-copy: Yes

Comparison to pipe: 7x faster
Comparison to Unix socket: 6x faster

Project 13: System V Shared Memory Image Processor

File: P13-sysv-shm-images.md
Main Programming Language: C
Coolness Level: Level 3 (Genuinely Clever)
Business Potential: Level 2 (Micro-SaaS)
Difficulty: Level 3 (Advanced)
Knowledge Area: Image Processing, Parallel Computing

What you’ll build: An image processing pipeline where multiple worker processes share a large image in System V shared memory.

Why it teaches IPC: Large data (images, matrices) should never be copied through pipes. Shared memory lets workers operate on the same data.

Core challenges you’ll face:

Segment sizing → shmget with large sizes
Work partitioning → Each worker processes a region
Coordination → Signaling when all workers are done

Real World Outcome

$ ./shm_image_filter input.png output.png --filter=blur --workers=4

Shared Memory Image Processor
Image: 4096x4096 (64MB)
Workers: 4
Filter: Gaussian blur

[Master] Loaded image into shared memory (shmid=54321)
[Worker 1] Processing rows 0-1023
[Worker 2] Processing rows 1024-2047
[Worker 3] Processing rows 2048-3071
[Worker 4] Processing rows 3072-4095
[Worker 2] Done (245ms)
[Worker 1] Done (251ms)
[Worker 4] Done (248ms)
[Worker 3] Done (250ms)
[Master] All workers complete, writing output

Total time: 255ms (vs 980ms single-threaded)
Speedup: 3.84x with 4 workers

Project 14: Memory-Mapped File Database

File: P14-mmap-database.md
Main Programming Language: C
Coolness Level: Level 4 (Hardcore Tech Flex)
Business Potential: Level 3 (Service & Support)
Difficulty: Level 4 (Expert)
Knowledge Area: Databases, File Systems

What you’ll build: A simple embedded database using mmap() for zero-copy persistence.

Why it teaches IPC: mmap() is shared memory backed by a file. Changes persist automatically. This is how SQLite, LMDB, and other embedded databases work.

Core challenges you’ll face:

File growth → Remapping when database grows
Crash consistency → msync and fsync
Concurrent access → Record locking + mmap

Real World Outcome

$ ./mmapdb create mydata.db --size=100MB
Database created: mydata.db (100MB)

$ ./mmapdb insert mydata.db user:1 '{"name":"Alice"}'
Inserted at offset 0

$ ./mmapdb insert mydata.db user:2 '{"name":"Bob"}'
Inserted at offset 256

$ ./mmapdb get mydata.db user:1
{"name":"Alice"}

# Kill the process abruptly
$ ./mmapdb insert mydata.db user:3 '{"name":"Charlie"}' &
$ kill -9 $!

# Data still persists (mmap wrote to file)
$ ./mmapdb get mydata.db user:3
{"name":"Charlie"}

Project 15: Lock-Free SPSC Queue

File: P15-lockfree-spsc.md
Main Programming Language: C
Alternative Programming Languages: Rust, C++
Coolness Level: Level 5 (Pure Magic)
Business Potential: Level 4 (Open Core)
Difficulty: Level 5 (Master)
Knowledge Area: Lock-Free Programming, Memory Models

What you’ll build: A single-producer single-consumer lock-free queue in shared memory using only atomic operations.

Why it teaches IPC: Lock-free programming eliminates mutex overhead but requires understanding memory ordering. This is how high-frequency trading systems work.

Core challenges you’ll face:

Memory barriers → __atomic_thread_fence, seq_cst vs relaxed
False sharing → Cache line padding
ABA problem → Sequence numbers

Real World Outcome

$ ./lockfree_bench --iterations=100M

Lock-Free SPSC Queue Benchmark
Operations: 100 million

Lock-free queue: 45M ops/sec
Mutex-based queue: 8M ops/sec
Semaphore-based: 6M ops/sec

Speedup: 5.6x over mutex
Latency (p99): 22ns vs 180ns

Project 16: Basic RPC Calculator

File: P16-rpc-calculator.md
Main Programming Language: C
Coolness Level: Level 3 (Genuinely Clever)
Business Potential: Level 2 (Micro-SaaS)
Difficulty: Level 3 (Advanced)
Knowledge Area: Distributed Systems, RPC

What you’ll build: A calculator service using Sun RPC with rpcgen-generated stubs.

Why it teaches IPC: RPC extends IPC across network boundaries. You’ll see how rpcgen generates client stubs, server skeletons, and XDR serialization.

Core challenges you’ll face:

rpcgen syntax → Writing .x interface files
XDR types → Serializing complex structures
portmapper → Registering and looking up services

Real World Outcome

# Define the interface (calc.x)
$ cat calc.x
program CALC_PROG {
    version CALC_VERS {
        int ADD(operands) = 1;
        int SUBTRACT(operands) = 2;
        int MULTIPLY(operands) = 3;
    } = 1;
} = 0x31230000;

# Generate stubs
$ rpcgen calc.x
# Creates: calc.h, calc_clnt.c, calc_svc.c, calc_xdr.c

# Start server
$ ./calc_server &
Registered with portmapper: program 0x31230000, version 1

# Run client
$ ./calc_client localhost add 5 3
Result: 8

$ ./calc_client localhost multiply 7 6
Result: 42

# Query portmapper
$ rpcinfo -p localhost | grep 31230000
    100000    4   tcp    111  portmapper
0x31230000    1   tcp  45678  calc

Project 17: RPC with Authentication

File: P17-rpc-auth.md
Main Programming Language: C
Coolness Level: Level 3 (Genuinely Clever)
Business Potential: Level 3 (Service & Support)
Difficulty: Level 3 (Advanced)
Knowledge Area: Security, RPC

What you’ll build: Extend the RPC calculator with AUTH_SYS (Unix) and AUTH_DES authentication.

Why it teaches IPC: Real RPC services need authentication. You’ll see how Sun RPC’s pluggable authentication works.

Project 18: Distributed Key-Value Store with RPC

File: P18-rpc-kvstore.md
Main Programming Language: C
Coolness Level: Level 4 (Hardcore Tech Flex)
Business Potential: Level 4 (Open Core)
Difficulty: Level 4 (Expert)
Knowledge Area: Distributed Systems, Storage

What you’ll build: A multi-server key-value store using RPC for client-server and server-server communication.

Why it teaches IPC: This combines everything: RPC for remote calls, shared memory for local caching, semaphores for coordination.

Real World Outcome

# Start 3 server replicas
$ ./kv_server --id=1 --port=9001 --peers=localhost:9002,localhost:9003 &
$ ./kv_server --id=2 --port=9002 --peers=localhost:9001,localhost:9003 &
$ ./kv_server --id=3 --port=9003 --peers=localhost:9001,localhost:9002 &

# Client connects to any server
$ ./kv_client --server=localhost:9001 put mykey "Hello World"
OK (replicated to 3 nodes)

$ ./kv_client --server=localhost:9002 get mykey
Hello World

# Kill a server, data still available
$ kill %1
$ ./kv_client --server=localhost:9002 get mykey
Hello World

Project Comparison Table

Project	Difficulty	Time	Depth of Understanding	Fun Factor
1. Shell Pipeline	Level 2	Weekend	High	★★★★☆
2. FIFO Client-Server	Level 2	Weekend	Medium	★★★☆☆
3. Implement popen	Level 3	1 Week	High	★★★★☆
4. POSIX MQ Dispatcher	Level 3	1 Week	High	★★★★☆
5. System V MQ Server	Level 3	1 Week	High	★★★☆☆
6. MQ Benchmark	Level 2	Weekend	Medium	★★★☆☆
7. Producer-Consumer	Level 3	1 Week	Very High	★★★★★
8. RWLock Implementation	Level 4	2 Weeks	Very High	★★★★☆
9. Record Locking DB	Level 3	1 Week	High	★★★☆☆
10. Semaphore Pool	Level 3	1 Week	High	★★★★☆
11. System V Barrier	Level 3	1 Week	High	★★★☆☆
12. SHM Ring Buffer	Level 4	2 Weeks	Very High	★★★★★
13. SHM Image Processor	Level 3	1 Week	Medium	★★★★☆
14. mmap Database	Level 4	2 Weeks	Very High	★★★★★
15. Lock-Free Queue	Level 5	3 Weeks	Extreme	★★★★★
16. RPC Calculator	Level 3	1 Week	High	★★★☆☆
17. RPC Authentication	Level 3	1 Week	Medium	★★★☆☆
18. Distributed KV Store	Level 4	3 Weeks	Very High	★★★★★

Recommendation

If you are new to IPC: Start with Project 1 (Shell Pipeline). It uses only pipes and fork(), the most fundamental IPC primitives.

If you are a systems programmer: Start with Project 7 (Producer-Consumer). Mutexes and condition variables are the foundation of all concurrent code.

If you want high performance: Focus on Projects 12-15 (Shared Memory). This is where the real speed gains happen.

If you need distributed systems: Start with Projects 16-18 (RPC). Understanding Sun RPC helps you appreciate modern alternatives like gRPC.

Final Overall Project: Unix IPC Integration Test Suite

The Goal: Combine all your implementations into a comprehensive IPC benchmark and test harness.

Create a unified library with all IPC mechanisms
Build a benchmark CLI that compares them all
Add stress tests that verify correctness under load
Generate reports with performance comparisons
Document the trade-offs you discovered

Success Criteria: You can run ./ipc_suite benchmark --all and get a complete comparison of every IPC mechanism, with correctness verification and performance metrics.

From Learning to Production: What’s Next?

After completing these projects, you’ve built educational implementations. Here’s how to transition to production-grade systems:

What You Built vs. What Production Needs

Your Project	Production Equivalent	Gap to Fill
Shared Memory Ring Buffer	LMAX Disruptor, io_uring	Lock-free MPMC, batch operations
Message Queue Dispatcher	RabbitMQ, ZeroMQ	Persistence, clustering, acknowledgments
RPC Calculator	gRPC, Apache Thrift	HTTP/2, streaming, load balancing
mmap Database	LMDB, SQLite	B-trees, ACID transactions, crash recovery

Skills You Now Have

You can confidently discuss:

The trade-offs between POSIX and System V IPC
When to use shared memory vs message passing
How to avoid deadlocks and race conditions
Memory ordering and lock-free programming basics

You can read source code of:

PostgreSQL (shared buffers, semaphores)
Redis (client-server, fork for persistence)
Nginx (worker processes, shared memory)
ZeroMQ (message queues, patterns)

You can architect:

Multi-process servers with shared state
High-performance data pipelines
Distributed systems with RPC

Recommended Next Steps

1. Contribute to Open Source:

libuv: Node.js’s cross-platform IPC layer
ZeroMQ: Modern message queue patterns

2. Build Production Systems:

Replace Sun RPC with gRPC in Project 18
Add persistence to your message queue
Implement a proper B-tree for the mmap database

3. Get Certified:

Linux Foundation Certified System Administrator (LFCS)
Linux Foundation Certified Engineer (LFCE)

Career Paths Unlocked

With this knowledge, you can pursue:

Systems Programming (databases, file systems)
Infrastructure Engineering (containers, orchestration)
Performance Engineering (low-latency trading, games)
Distributed Systems (cloud platforms, data pipelines)

Summary

This learning path covers Unix IPC through 18 hands-on projects.

#	Project Name	Main Language	Difficulty	Time Estimate
1	Shell Pipeline Executor	C	Level 2	Weekend
2	FIFO Client-Server	C	Level 2	Weekend
3	Implement popen	C	Level 3	1 Week
4	POSIX MQ Dispatcher	C	Level 3	1 Week
5	System V MQ Server	C	Level 3	1 Week
6	MQ Benchmark	C	Level 2	Weekend
7	Producer-Consumer	C	Level 3	1 Week
8	RWLock Implementation	C	Level 4	2 Weeks
9	Record Locking DB	C	Level 3	1 Week
10	Semaphore Pool	C	Level 3	1 Week
11	System V Barrier	C	Level 3	1 Week
12	SHM Ring Buffer	C	Level 4	2 Weeks
13	SHM Image Processor	C	Level 3	1 Week
14	mmap Database	C	Level 4	2 Weeks
15	Lock-Free Queue	C	Level 5	3 Weeks
16	RPC Calculator	C	Level 3	1 Week
17	RPC Authentication	C	Level 3	1 Week
18	Distributed KV Store	C	Level 4	3 Weeks

Expected Outcomes

After completing these projects, you will:

Understand every IPC mechanism in Unix at the system call level
Know exactly when to use pipes vs message queues vs shared memory
Be able to debug race conditions and deadlocks systematically
Have performance intuition for each IPC mechanism
Be prepared for systems programming interviews at any company

You’ll have built a complete IPC toolkit from first principles, covering everything in Stevens’ Unix Network Programming Volume 2.

Additional Resources & References

Standards & Specifications

Online Guides

Beej’s Guide to IPC - Excellent free online resource
Opensource.com IPC Series

Books

IPC Specific:

“Unix Network Programming Volume 2” by W. Richard Stevens (Prentice Hall) - THE definitive reference
“The Linux Programming Interface” by Michael Kerrisk (No Starch Press) - Modern Linux-specific coverage

Concurrency:

“Programming with POSIX Threads” by David Butenhof - Pthreads bible
“Rust Atomics and Locks” by Mara Bos - Modern take on lock-free programming

Foundations (from your library):

“Advanced Programming in the UNIX Environment” by Stevens & Rago - System programming context
“Operating Systems: Three Easy Pieces” by Arpaci-Dusseau - Theoretical foundation
“Computer Systems: A Programmer’s Perspective” by Bryant & O’Hallaron - Understanding the machine

This guide covers every IPC mechanism from W. Richard Stevens’ “Unix Network Programming Volume 2: Interprocess Communications.” Work through all 18 projects to achieve complete mastery of Unix IPC.