Grokking Concurrency: Chapter 5 — Interprocess Communication
In Chapter 5 of Grokking Concurrency, the focus shifts to how the fundamental building blocks interact: Interprocess Communication (IPC). If you are interested in exploring the practical code implementations and detailed diagrams of these communication models, I highly recommend reading the full book, which covers these concepts in much greater detail.
Concurrent tasks often require communication and coordination, especially when one task depends on another. Therefore, operating systems provide mechanisms that enable processes and threads to exchange information and synchronize their work efficiently. This mechanism is known as interprocess communication (IPC).
Let’s look at different types of IPC:
Shared-memory IPC:
IPC is the mechanism operating systems provide to allow processes and threads to exchange information and synchronize their work.
Tasks communicate by reading and writing to the same memory space instantly.
- The Pro: It is incredibly fast. Tasks talk directly without the OS slowing things down.
- The Con: Highly risky. Without strict protection, tasks can easily overwrite each other’s data.
Imagine a team of people working in the same room.
Imagine a team in a room sharing one whiteboard. Anyone can write, read, or erase instantly. It’s fast because no one is sending emails, but dangerous because two people might write over each other at the same time.
Message-passing IPC:
Tasks communicate by sending messages through channels explicitly managed by the OS.
- The Pro: Safe and simple. The OS isolated the data, and it scales perfectly across multiple machines.
- The Con: Slower, because data must be copied through the OS kernel every time.
It is like Sending Letters Through a Post Office
Instead of sharing a board, Person A writes a letter and drops it at the post office (the OS), which delivers it to Person B. It takes longer, but Person A can never accidentally erase Person B’s notes.
Pipes:
A simple, temporary, one-way data stream between two related tasks.
How it works: One task writes bytes in; the other reads bytes out. If you need two-way communication, you must open a second pipe.
Get Sahar Asadian’s stories in your inbox
Join Medium for free to get updates from this writer.
Imagine two rooms connected by a one‑way intercom:
Room A has a microphone; Room B has a speaker. Information only flows from A to B. It’s simple, but if you want to talk back, you have to install a whole new intercom.
Message queues:
Message queues let many tasks send and receive messages in FIFO order, acting as a shared mailbox that decouples producers and consumers.
Imagine a busy bakery:
The Bakery Analogy: Customers drop written order tickets into a box. Bakers pull the oldest ticket from the box, fulfill it, and move on. Customers and bakers never talk directly, decoupling the system perfectly.
UNIX Domain Sockets (UDS)
A dedicated, two-way connection channel between two endpoints. While traditional sockets work across a network, UDS is optimized specifically for ultra-fast communication on the same machine.
The Walkie-Talkie Analogy:
Two people pair their walkie-talkies. Either person can press the button to speak and listen on a private, direct, two-way line. No shared whiteboard, no mailbox delays.
The Thread Pool Pattern
Managing threads manually is expensive and messy. A Concurrency Pattern is a proven architectural blueprint to solve this, and the Thread Pool is the most common.
Instead of creating a new thread for every incoming task, a Thread Pool keeps a fixed number of long-running worker threads alive and reuses them.
Why use a Thread Pool?
- Saves Resources: Bypasses the high CPU cost of constantly creating and destroying threads.
- Resilience: If a task crashes or throws an exception, the worker thread stays alive to take the next job.
- Speed: Crucial for short tasks, where creating a thread would actually take longer than doing the work itself.
The Restaurant Analogy:
A busy restaurant doesn’t hire a new waiter every single time, when a new customer walks through the door. Instead, they keep a fixed staff of waiters. When a waiter finishes serving Table 1, they immediately pivot to serve Table 2. Same staff, hundreds of customers served.
This was a summary of Chapter 5. Stay tuned for next week’s breakdown of Chapter 6, where we will transition into Part 2 of the book and dive into Multitasking.
I hope this article provided you with some helpful insights. Follow me for more content.
Happy Coding!
