🧵 OS 02: Process vs Thread & Inter-Process Communication (IPC)

Targeted for: Juspay Elimination Round, Hackathon Part B System Discussion & High-Concurrency Architecture
Key Focus: Memory isolation vs sharing, Kernel vs User threads, IPC deep dive (Pipes, Shared Memory, Message Queues, Sockets), and Thread Lifecycle.

⚖️ 1. Process vs Thread: The Complete Comparison

Comprehensive Comparison Matrix

🔄 2. Thread Lifecycle States

Threads follow a refined state transition model closely aligned with OS and runtime execution (e.g., POSIX pthreads, Java/JVM Thread States):

Thread States Explained

1. NEW: The thread object has been created in memory, but start() / pthread_create() has not yet been called. The kernel thread has not spawned.
2. RUNNABLE / READY: The thread is eligible to run and sits in the OS Ready Queue awaiting CPU time.
3. RUNNING: The thread is actively executing instructions on a physical CPU core.
4. BLOCKED: The thread is suspended waiting to acquire an exclusive lock (e.g., waiting outside a synchronized block or pthread_mutex_lock).
5. WAITING: The thread has explicitly paused its own execution indefinitely (e.g., calling wait(), pthread_cond_wait(), or thread.join()). It will not wake up until another thread sends a notification (notify() / pthread_cond_signal()).
6. TIMED_WAITING: The thread is paused for a specified duration (e.g., sleep(1000), poll(timeout)).
7. TERMINATED (DEAD): The thread has completed its execution or was terminated due to an uncaught exception. Its stack is deallocated.

🧵 3. Threading Models: User-Level vs Kernel-Level

1. Many-to-One (N:1 - Green Threads):
   • User space library schedules threads without kernel awareness.
   • Advantage: Ultra-fast context switching (no kernel transitions).
   • Fatal Flaw: If one thread makes a blocking I/O call, the OS blocks the entire process (all user threads freeze). Cannot utilize multicore CPUs in parallel.
2. One-to-One (1:1 - POSIX pthreads, Java threads, C++ std::thread):
   • Every user thread maps directly to an OS kernel thread (task_struct).
   • Advantage: True multicore hardware parallelism. A blocking thread does not block siblings.
   • Disadvantage: Higher memory footprint (~2MB stack per thread) and context switch requires a kernel mode switch.
3. Many-to-Many (M:N - Hybrid / Go Goroutines / Kotlin Coroutines):
   • Multiplexes $M$ lightweight user tasks over $N$ kernel worker threads.
   • Goroutines start with a tiny 2KB dynamic stack, allowing millions of concurrent tasks with microsecond scheduling.

📡 4. Inter-Process Communication (IPC) Deep Dive

When processes must cooperate, they cannot simply read each other's memory. The OS provides 6 distinct IPC Mechanisms:

Detailed Breakdown of Each Mechanism

1. Pipes (Anonymous & Named)

• Anonymous Pipes (pipe() system call):
  • Unidirectional (Half-duplex) byte stream between parent and child processes created before fork().
  • Managed inside a circular kernel buffer (typically 64 KB).
  • Example in shell: cat transactions.log | grep "FAILED" | wc -l.
• Named Pipes / FIFOs (mkfifo() system call):
  • Appears as a special FIFO file on the filesystem (e.g., /tmp/payment_pipe).
  • Allows communication between completely unrelated processes running under different user accounts.

2. Message Queues (POSIX mq_open / mq_send / mq_receive)

• Stores structured messages in a kernel-managed linked list.
• Unlike byte-stream pipes, message queues preserve message boundaries and support message priorities (higher-priority messages are dequeued before older, lower-priority ones).

3. Shared Memory (shmget / shmat or POSIX shm_open + mmap) — 🔥 The Gold Standard for Speed

• The OS maps the exact same physical RAM frames into the virtual address spaces of two or more independent processes.
• Zero-Copy Architecture: Data written by Process A is immediately visible to Process B at memory bus speed without copying bytes through kernel space.
• The Catch: The OS provides no synchronization. Processes must coordinate concurrent reads/writes using POSIX named semaphores (sem_open) or process-shared mutexes (PTHREAD_PROCESS_SHARED).

4. Sockets (Unix Domain Sockets vs TCP/IP Sockets)

• Unix Domain Sockets (AF_UNIX / AF_LOCAL):
  • Optimized local IPC. Uses standard socket API (socket(), bind(), connect()), but data transfers occur entirely in-memory inside the kernel without packetizing, checksumming, or TCP/IP routing overhead.
  • Standard for local database connections (e.g., PostgreSQL /var/run/postgresql/.s.PGSQL.5432 or Redis /var/run/redis/redis.sock).
• Network Sockets (AF_INET - TCP/UDP):
  • Enables communication across physical network boundaries. Heavyweight protocol overhead, but universal.

5. Signals (kill() system call)

• Asynchronous notifications sent from the kernel or another process (e.g., SIGINT (Ctrl+C), SIGTERM (graceful shutdown), SIGKILL (immediate uncatchable termination), SIGCHLD (child state change)).
• Cannot carry complex data payloads (limited to signal number and optional siginfo_t).

🎯 5. When to Use Which: Architectural Decision Framework

Real-World Production Examples

1. Google Chrome Architecture (Multi-Process):
   • Each browser tab runs in an isolated process. If an untrusted JavaScript script crashes or infinite loops in Tab 1, Tabs 2, 3, and 4 continue running smoothly. Tab processes communicate with the main Browser process via Named Pipes / Mojo IPC.
2. Nginx Web Server (Multi-Process + Shared Memory):
   • Nginx runs 1 Master process and $N$ Worker processes (one per CPU core). Worker processes share connection limits, cache metadata, and rate-limiting counters via Shared Memory zones (shm) with spinlocks.
3. High-Throughput Payment Engine (Juspay Context):
   • High-throughput processing threads within the same process share the M-ary tree state directly on the Heap. Cross-service transaction logging delegates to Redis / Kafka via TCP Sockets or local Unix Sockets.

💬 6. Verbatim Interview Scripts (Say This Out Loud)

Q: "When would you choose multiple processes over multiple threads for a system?"

Verbatim Answer:
"I choose multiple processes when fault isolation, security sandboxing, or privilege separation is paramount. In a multi-process architecture (like Google Chrome tabs or Nginx worker processes), if one worker suffers a memory corruption or segfault, other workers and the main daemon remain fully operational. Furthermore, processes can run under distinct OS user privileges and security policies.

Conversely, I choose multiple threads when ultra-low latency, high shared-state throughput, and frequent context switches are required. Threads share the same address space, avoiding IPC serialization costs and heavy kernel context switches. However, threads require rigorous concurrency synchronization since a single unhandled exception will crash the entire process."

Q: "What is the fastest IPC mechanism available on Linux, and what is its primary drawback?"

Verbatim Answer:
"The fastest IPC mechanism is Shared Memory (shm_open + mmap or shmget). It maps the same physical memory frames into the virtual address spaces of communicating processes. Once mapped, reads and writes occur directly at hardware memory bus speeds with zero kernel context switches and zero intermediate buffer copying.

Its primary drawback is that the OS provides no built-in synchronization. Unlike pipes or message queues, shared memory does not block a reader when data is not ready, nor does it prevent race conditions. Developers must explicitly implement synchronization using POSIX named semaphores, process-shared mutexes, or atomic CAS operations."