What Is the Difference Between a Process and a Thread?

Question and when to use it

An application must run 8 CPU-bound third-party plugins that may crash or hang and serve up to 2,000 concurrent I/O-bound requests that share a large read-mostly cache. Explain the difference between a process and a thread, then choose an execution model for each workload. Cover resource ownership, scheduling, communication, synchronization, failure and security isolation, lifecycle, and validation.

This is an operating-systems fundamentals question for software, backend, infrastructure, and systems roles. The numbers 8 and 2,000 are interview assumptions, not universal sizing rules. The first workload values isolation and CPU parallelism; the second values high I/O concurrency and efficient access to common data. A useful answer derives two choices from those constraints instead of declaring processes or threads universally faster.

What the interviewer is evaluating

The first signal is an accurate ownership model. A process is a resource and isolation container with a virtual address space, executable code, open system resources, security context, and at least one thread. A thread is a schedulable execution context inside that process. Threads in one process share its address space and process-wide resources, while each thread keeps execution state such as registers, a stack, a thread identifier, and thread-local storage.

The second signal is whether the candidate separates concurrency from parallelism. Multiple tasks can make progress concurrently on one core by interleaving. They execute in parallel only when the runtime and operating system run them on multiple cores. Creating 2,000 threads does not create 2,000-way CPU parallelism, and eight CPU-bound jobs do not imply that eight worker processes fit the machine's CPU and memory budgets.

The third signal is engineering judgment. Shared memory makes thread communication direct but creates races, lock contention, and process-wide failure risk. Separate processes provide a stronger default fault and memory boundary but need IPC, supervision, and serialization or shared-memory protocols. Process isolation alone is not a complete sandbox for untrusted code; privileges, system calls, files, network access, CPU, and memory also need limits.

Questions to clarify before answering

• What does “third-party” mean? Trusted but buggy code mainly needs crash and hang isolation. Adversarial code also requires a real sandbox, least privilege, and resource controls.
• Must the plugins share a large model or cache? Independent memory favors processes. A very large read-only data set may need a shared read-only mapping to avoid one physical copy per worker.
• Does the language runtime permit CPU-bound threads to run in parallel? Native threads can use multiple cores, but a runtime lock or scheduler may serialize application code and change the choice.
• Are request handlers using blocking or nonblocking libraries? Blocking dependencies fit a bounded thread pool. A fully nonblocking stack can serve many waiting connections with an event loop and fewer operating-system threads.
• Can the cache be immutable or versioned? An immutable snapshot with atomic replacement is easier to share safely than a mutable object graph requiring fine-grained locks.
• What are the failure and latency objectives? A plugin deadline, restart budget, request p99, cancellation contract, memory limit, and overload policy determine pool sizes and queue bounds.

30-second answer framework

“A process owns an isolated virtual address space and process-wide resources; it contains one or more threads. Threads are schedulable execution contexts that share that process state but keep their own stack, registers, identifier, and thread-local state. I would run crash-prone CPU plugins in supervised, resource-limited processes so a fault or hang can be terminated and replaced without sharing the host heap; the worker count follows CPU and memory budgets, not the number eight automatically. For 2,000 mostly waiting requests, I would use an async event loop when the whole dependency path is nonblocking, or a bounded thread pool when libraries block. Threads can share the read-mostly cache, preferably as immutable snapshots. I would benchmark throughput, p99, memory, context switches, IPC or lock wait, and inject crashes, hangs, and races before deciding.”

Step-by-step solution

Step 1: Build the ownership model

The portable mental model is a process as the resource boundary and a thread as an execution flow within it. Exact kernel implementation differs by platform, so avoid presenting one operating system's internal object model as universal.

“Separate by default” matters. Processes can deliberately share memory, files, and handles; threads can communicate through queues instead of arbitrary shared mutation. The choice controls the default failure and ownership boundary, not the only possible communication API.

Step 2: Separate concurrency, parallelism, and cost

Concurrency means multiple units of work remain in progress. Parallelism means work executes at the same instant on different processing resources. One thread can multiplex many asynchronous I/O operations; multiple runnable threads or processes can use multiple cores. The actual CPU parallelism is bounded by available cores, container quotas, and runtime behavior.

Threads are commonly cheaper to create and switch between because they reuse one address space, while processes commonly carry more memory and lifecycle state. That is a direction, not a performance guarantee. Copy-on-write process creation, thread stack reservations, cache misses, address-space changes, runtime scheduling, IPC payloads, and lock contention can reverse the important cost for a particular workload. Do not attach a universal microsecond or memory number; measure the target runtime and platform.

Step 3: Compare communication and correctness costs

Threads can pass a pointer to shared data, but every mutable object needs an ownership or synchronization rule. Two threads performing a read-modify-write on one cache entry can lose an update even though each source line looks simple. Locks, atomics, immutable data, message passing, or partitioned ownership solve different access patterns. A lock that preserves correctness can still produce long queueing and p99 latency under contention.

Processes normally exchange messages through pipes, sockets, queues, or RPC. This creates an explicit protocol and makes ownership easier to audit, at the cost of serialization, copying, backpressure, and partial-failure handling. Shared memory can remove copies, but then the processes again need a versioning and synchronization protocol. IPC does not remove concurrency bugs; it moves them to message identity, ordering, retry, timeout, and lifecycle boundaries.

Step 4: Choose supervised processes for the plugin workload

For the 8 CPU-bound third-party jobs, use a bounded process-worker pool supervised by the host. Give each job an identifier, input contract, deadline, output contract, and cancellation behavior. A worker that exits, exceeds its deadline, or breaches a resource limit is terminated and replaced; the supervisor decides whether the job is safe to retry. Keep plugin state out of the host heap and pass explicit inputs and outputs.

The pool size comes from CPU quota, plugin memory, and service headroom. On a four-core quota, starting eight permanently runnable workers may increase context switching without reducing total CPU work. If plugins need a large common read-only data set, map a validated read-only snapshot into workers or run a dedicated data service; do not abandon fault isolation merely to avoid an assumed copy.

A separate process is only one security layer. Potentially hostile plugins need a restricted identity, sandbox or container boundary, allowed system-call policy where available, filesystem and network restrictions, CPU and memory quotas, and an output validator. Also isolate the supervisor from a flood of worker logs, crash files, and restart attempts.

Step 5: Choose async I/O or a bounded thread pool for requests

For up to 2,000 concurrent requests that spend most of their time waiting, do not map “one request” directly to “one new process.” If the network, database, and client libraries are nonblocking end to end, an event loop can keep many requests in flight on a small number of threads. CPU-heavy work must leave the event loop, and every queue needs a bound so overload becomes rejection or backpressure instead of unbounded memory growth.

If a required library blocks, use a bounded thread pool sized and measured against that dependency. The bound protects memory, open connections, and downstream capacity. Threads can access the read-mostly cache without IPC; publish an immutable, versioned snapshot through an atomic reference when possible. If mutation is unavoidable, define the lock scope and measure contention. Combining an event loop for sockets with a bounded blocking-work pool is often more accurate than choosing only “threads” or “async.”

Step 6: Validate the decision with measurements and faults

Benchmark both candidates on the same machine or quota with production-like payloads and wait ratios. Record throughput, p50 and p99 latency, CPU utilization, resident and proportional memory, queue time, context switches, IPC bytes and serialization time for processes, and lock wait plus event-loop lag for threaded or async designs. Warm-up, input distribution, worker count, and queue limits must be identical when comparing results.

Test boundaries as aggressively as the happy path:

1. Crash a plugin and verify the host and sibling workers remain available, the exit is observed, and restart policy is bounded.
2. Hang a plugin and verify the deadline, termination, cleanup, and retry decision.
3. Force plugin memory and log growth and verify quotas protect the host.
4. Stress concurrent cache reads and refreshes; use a race detector when the runtime provides one and verify readers see a complete old or new snapshot.
5. Saturate request handling and verify bounded queues, cancellation, downstream limits, and overload responses.
6. Restart the service and verify in-flight ownership is either recovered or failed according to the contract.

The reusable decision rule is: choose the process boundary when isolation, independent lifecycle, or runtime CPU parallelism dominates; choose shared threads when low-cost access to common in-process state dominates and synchronization remains tractable; choose async tasks when waiting concurrency dominates and the dependency chain supports nonblocking cancellation. Validate the boundary that can fail, not only peak throughput.

Example of a strong answer

“I would start with ownership. A process has its own virtual address space and process-wide resources and contains at least one thread. Threads in that process share its heap and open resources, while each thread has its own stack, registers, identifier, and thread-local state. This makes threads convenient for shared data, but a bad write or fatal failure can affect the whole process. Processes make communication more explicit and provide a stronger default fault boundary, although shared memory and inherited resources mean the boundary is configurable.

For the eight CPU-bound plugins, I would use supervised worker processes. The supervisor sends a job with an ID and deadline, validates the result, observes exits, and replaces failed workers with a restart budget. Worker count follows CPU quota and memory measurements; eight jobs do not automatically mean eight workers. If the plugins are untrusted, separate processes are necessary but insufficient, so I would also restrict privileges, system calls, files, network, CPU, and memory.

For 2,000 mostly I/O-waiting requests, I would inspect the libraries. With a nonblocking path I would use an event loop and move CPU work to a bounded pool. With blocking dependencies I would use a bounded thread pool. The read-mostly cache would be an immutable versioned snapshot published atomically, avoiding a lock on every read. Every queue and downstream call has a deadline and capacity limit.

I would compare throughput and p99 together with CPU, memory, queue time, context switches, IPC or lock wait, and event-loop lag. Then I would crash, hang, and memory-stress plugins and race the cache refresh. The design wins only if its isolation and correctness claims survive those faults, not because threads or processes are generally called lighter.”

Common mistakes

• Saying a process is a program and a thread is a function → This omits resource ownership and schedulable state → Describe the process address-space boundary and the thread's shared and private execution state.
• Claiming threads share everything → Each thread has its own stack, registers, identifier, and thread-local state → List process-wide and per-thread state separately.
• Claiming processes cannot share memory → Explicit shared mappings are possible → Say processes are isolated by default and explain the protocol required to share safely.
• Calling concurrency and parallelism synonyms → Work can interleave on one core without executing simultaneously → Tie parallelism to cores, quotas, and runtime behavior.
• Choosing eight workers because there are eight jobs → Runnable workers compete for finite CPU and memory → Size the pool from quotas, measurements, and service headroom.
• Using a process as the complete untrusted-code sandbox → A process can still access permitted files, network, and kernel interfaces or exhaust resources → Add least privilege, sandbox policy, quotas, and output validation.
• Creating one thread for every waiting request without a bound → Stack memory, scheduling, and downstream calls can exhaust the service → Use async I/O or a measured bounded pool with backpressure.
• Sharing a mutable cache without an ownership rule → Data races and lock contention can break correctness or tail latency → Prefer immutable snapshots or define and test synchronization.
• Comparing only average throughput → A design can hide p99 queueing, memory growth, or weak isolation → Measure latency distributions and inject crashes, hangs, saturation, and races.
• Assuming threads are always faster → Runtime, IPC, cache, lock, and workload costs vary → Treat lower overhead as a hypothesis and benchmark the real implementation.

Follow-up questions and responses

Follow-up 1: Can processes still share the 20 GB read-only model?

Yes. Map a validated, immutable file or shared-memory region read-only into each worker so physical pages can be shared where the operating system supports it. Version the mapping and switch workers to a new snapshot rather than modifying it in place. Measure page-fault and residency behavior, and keep per-request mutable state outside the shared region.

Follow-up 2: What changes if the language runtime serializes CPU-bound threads?

Verify the exact runtime and workload; a lock may cover only managed-language execution while native libraries release it. If CPU work is serialized, use worker processes or a runtime facility that provides true parallel execution. Preserve bounded queues and cancellation, because changing the worker primitive does not solve overload.

Follow-up 3: Does one blocked thread stop the whole process?

Normally, another runnable thread can continue. The process can still stall if the blocked thread holds a lock, owns a required event loop, exhausts a shared pool, or waits inside a process-wide initialization path. Diagnose the dependency and ownership graph instead of equating one blocked thread with one blocked process.

Follow-up 4: When is a thread pool better than an event loop?

A thread pool fits blocking libraries, modest concurrency, and code whose simplicity outweighs measured thread cost. An event loop fits large waiting concurrency when every important dependency supports nonblocking operations and cancellation. A hybrid uses the event loop for sockets and a bounded pool for unavoidable blocking work; its queue and deadline are part of the design.

Follow-up 5: How do you prevent one worker crash from causing a restart storm?

Classify exits, cap restarts in a time window, add backoff, quarantine repeatedly failing plugin versions, and keep admission closed when capacity is unsafe. Persist enough job state to decide whether an interrupted job is retryable. Alert on crash loops without sending unbounded logs or crash artifacts through the supervisor.

Follow-up 6: When should separate services replace local processes?

Use a service boundary when workers need independent deployment, scaling, ownership, language runtimes, or host-level security policies. The cost is network RPC, versioned contracts, discovery, distributed tracing, and partial failure. Local processes remain simpler when one host-level supervisor and local IPC satisfy the isolation and scaling requirements.