Threads and Processes

Under preemptive scheduling a timer interrupt lets the scheduler suspend a task at almost any instruction and run another. Under cooperative scheduling a task runs until it voluntarily yields. Preemption guarantees progress for everyone; cooperation is cheaper and predictable but one non-yielding task blocks all others.

Three mappings of program threads onto kernel-scheduled threads. 1:1 — each program thread is a kernel thread: real parallelism, but costly. N:1 — many on one: cheap, but no multicore and one blocking call stalls all. M:N — both benefits, at the price of a complex two-level scheduler.

Joining means one thread blocks until another finishes. Starting a thread only launches it; the starter keeps running and has no idea when the work is done or whether it succeeded. Join gives you completion timing and a safe point to read results.

The kernel saves the running thread's registers and program counter, picks another runnable thread, and restores its state; a switch to a different process also swaps page tables. The direct cost is small. The larger, indirect cost is cold caches, branch predictors and address-translation entries when the new thread starts running.

New (created, not started) → runnable (ready or actually running) → a non-runnable state → terminated, which is final. Blocked means it wants a lock someone else holds. Waiting means it voluntarily parked and needs another thread to signal it; timed-waiting also wakes on a deadline.

A variable whose value is per-thread: every thread reading the same name gets its own copy, so no synchronization is needed. It solves sharing non-thread-safe or per-request state without locks. It costs you invisible coupling, lifetime bugs on reused threads, and memory that scales with thread count.

A forced kill stops a thread at an arbitrary instruction, so it can leave shared data half-updated and locks held forever — damage the rest of the process cannot detect or repair. The replacement is cooperative cancellation: request a stop, and let the target check at safe points and unwind cleanly.

Thread-local values are keyed to the thread, and the background worker is a different thread with its own empty slot. The fix is to capture the context on the submitting thread at submission time, carry it with the task, and install it on the executing thread around the task — always removing it afterwards.

Pool threads never die, so a value left in a thread-local slot survives into the next request on that worker. That leaks memory and, worse, leaks data: a later request that forgets to set the identity silently inherits the previous caller's. Always clear in a finally block.

Fork clones the calling process, giving the child a duplicate address space and handle table; exec then replaces the child's program image with a new one. Copy-on-write makes the duplicate lazy — pages are shared read-only until written. Processes still cost more than threads: page tables, handle tables and kernel bookkeeping versus one stack.

A time slice bounds how long one task can hold a core, trading throughput for responsiveness: long slices amortize switch cost, short slices cut waiting time for others. Priorities bias the choice of who runs next; strict priority can starve low-priority work, so schedulers add aging or proportional shares.

An OS thread carries a large fixed stack reservation plus non-pageable kernel bookkeeping, and every switch is a trip through the kernel. A lightweight thread is a heap object with a tiny growable stack switched in user space — kilobytes, not megabytes. The new ceiling is heap and live stack depth.

The process stays alive while any ordinary (user) thread is still running; background (daemon) threads do not keep it alive and are abandoned mid-work when the last user thread ends. That makes them safe for infinite loops but unsafe for anything that must finish, like a buffered write.

Pipes are simple one-way byte streams via kernel buffers. Sockets are the same idea but routable across machines. Shared memory is the only zero-copy option — mapped by both sides, needing its own synchronization. Signals carry notification, not data. For high volume on one host, use shared memory with a ring buffer, or pipes if simplicity wins.

Beyond one runnable thread per core, throughput stops rising and eventually falls: extra threads add context switches, cache eviction and lock contention rather than work. Latency grows roughly with the queue of runnable threads. From outside you see high run-queue length, many involuntary context switches, high CPU with falling completion rate, and rising tail latency.

Pinning means a lightweight thread cannot be unmounted from its host OS thread — usually because it is blocked inside native code or in a construct whose state the runtime cannot relocate. The host is consumed while it waits, so effective parallelism shrinks; if all hosts pin, everything stops.

M:N buys cheap, numerous threads that still use every core. It is hard because a blocking system call removes a host kernel thread from service, and two schedulers must agree about priorities, signals, locks, and what debuggers and profilers see. Once kernel threads got cheap, the complexity stopped paying.

The thread's stack unwinds, a per-thread failure hook (or a default that prints to standard error) runs, and the thread terminates. Nothing propagates to whoever started it, so the failure is invisible unless you installed a hook — the symptom is silently missing work.

Capturing takes a snapshot at hand-off, so the task sees the context of the operation that created it, however late it runs. Re-reading sees whatever is current on the executing thread — usually empty or another task's leftovers. Capture is almost always what you want; re-read only suits genuinely global, dynamic settings.

Multi-process gives hardware-enforced fault and trust boundaries: a crash, leak or compromise is contained and the supervisor restarts one worker. It costs memory per worker, copying on every message, and slower startup. Multi-threaded is cheaper and shares state for free, but one bad pointer or hostile extension takes down everything.

Decide from in-flight concurrency and the fraction of time a request spends waiting, not from fashion. Lightweight threads win when tens of thousands of mostly-waiting requests must be represented. They invalidate pool-size-as-backpressure, thread-identity assumptions, OS priorities, per-thread buffers, and any blocking the runtime cannot mediate.

Split by consequence of being wrong. Values that change results or access — tenant, user, deadline — go in explicit parameters, so a missing value is a compile or call-site error. Values that only annotate — correlation ids, log tags — can be ambient, because losing them degrades diagnostics, not correctness.

Schedulers keep per-core run queues and prefer to resume a thread on its previous core, because its cached data is there; idle cores steal work from busy queues. Explicit pinning fixes a thread to chosen cores, protecting cache and memory locality for latency-critical work, at the cost of the scheduler's ability to balance load.