Katkat
Back

Compare Multithreading and Multiprocessing

Hudson River TradingSoftware Engineer · Technical Screen
MediumSoftware EngineerTechnical ScreenSoftware Engineering Fundamentals

Last updated

This question tests your understanding of concurrency primitives, operating system process models, memory isolation, context switching overheads, and the architectural trade-offs between threads and processes in low-latency systems.

Concurrency Architecture: Multithreading vs. Multiprocessing

In high-throughput, low-latency software engineering, selecting the appropriate execution model between multithreading and multiprocessing fundamentally dictates system performance, fault isolation, and complexity.

Provide an in-depth comparative analysis of multithreading and multiprocessing across operating system and hardware boundaries, followed by a concrete architectural recommendation for a specific systems scenario.

Part 1: Core Architectural Comparison

Compare the two paradigms across the following dimensions:

  1. Memory Model & Resource Allocation: How do threads and processes differ regarding virtual address space, heap, stack, file descriptors, and kernel resources?
  2. Context Switching Overhead: Compare the CPU overhead of thread-to-thread context switching versus process-to-process context switching. Explain the role of the translation lookaside buffer (TLB) and page table switching (CR3 register on x86-64).
  3. Inter-Communication & Synchronization: Compare synchronization within a process (mutexes, spinlocks, atomics) against inter-process communication (IPC: POSIX shared memory, Unix domain sockets, pipes). Address cache coherency and false sharing.
  4. Fault Tolerance & Safety: How does memory corruption (e.g., buffer overflow, null pointer dereference) or an unexpected termination in one execution unit affect others in each paradigm?

Part 2: Applied Scenario

Consider an algorithmic trading gateway that must:

  • Ingest a multi-gigabit UDP multicast market data feed.
  • Parse and maintain an in-memory limit order book (LOB).
  • Evaluate risk checks and route outbound orders over TCP.

Explain how you would partition these components across processes and threads. Which tasks should share a process via multithreading, and which tasks (if any) should be isolated across separate processes? Justify your decision with reference to latency, cache locality, core pinning (CPU affinity), and crash isolation.

Hints

Hint 1

Consider the cost of flushing or invalidating TLB entries when switching page tables versus switching kernel thread contexts within the same address space.

Hint 2

Think about memory safety: if an external market feed sends malformed data that triggers a segmentation fault, consider which parts of the trading pipeline must stay alive.

Hint 3

For the trading gateway, consider combining shared-memory IPC (`shm_open`, lock-free ring buffers) between isolated processes to gain both speed and crash resilience.

Follow-up questions

  • How does CPU cache coherence (MESI/MOESI protocols) impact multi-threaded performance when multiple threads write to adjacent bytes in the same 64-byte cache line?
  • If Python were chosen instead of C++, how does the Global Interpreter Lock (GIL) alter the fundamental trade-off between `threading` and `multiprocessing`?
  • How can you achieve near-zero context-switch latency for ultra-low latency threads using Linux real-time scheduling policies and core isolation (`isolcpus`, `taskset`)?