What does it mean to join a thread you started, and what problem does joining solve that simply starting the thread does not?

## What starting a thread actually does When you start a thread, you hand the runtime a function to execute and it schedules a new independent flow of control. The call returns immediately. From that instant there are two threads: the *starter*, which continues at the next statement, and the *child*, which begins executing its entry function whenever the scheduler picks it. Nothing coordinates them. The child may finish before the next line of the starter runs, or minutes later, or never. That is exactly the problem join solves. ## Join = wait for termination `join` (also called *await*, *wait for*, or in some runtimes simply waiting on the thread handle) blocks the calling thread until the target thread has terminated. While blocked, the joiner consumes no CPU; the scheduler wakes it when the target ends. Termination here means the target's entry function returned *or* threw an exception that escaped it. Either way, the thread is dead. Join does not tell you which happened — that is a common trap. If you need the outcome, the child must publish it: write a result into a shared slot, put it on a queue, or complete a future. ## The three guarantees join gives you **1. A visibility/ordering guarantee.** Under any realistic memory model, the actions of a thread that has terminated *happen-before* the return of a successful join on that thread. Concretely: the child can write to a plain, unsynchronized variable, and after join the parent may read it and is guaranteed to see the final value — no lock, no atomic needed. Without the join, reading that variable is a data race and the parent may observe a stale or partially-constructed value. This is the single most under-appreciated property of join in interviews. **2. Lifetime control.** Resources the child touches — buffers, file handles, memory it borrowed from the parent's stack in languages that permit that — can only be reclaimed once you know the child cannot touch them again. Join is the proof. It is also how a program guarantees that all work is complete before it exits, since in most runtimes the process may terminate while ordinary background threads are still running. **3. Structure.** Join is what turns an unbounded fan-out into a bounded, scoped operation: ``` results = array of N slots threads = for i in 0..N-1: start(worker(i, results)) for t in threads: t.join() combine(results) ``` After the loop, every worker is finished and every slot is safely readable. The lifetime of the child threads is nested inside the lifetime of the block that created them. This nesting is the seed of *structured concurrency*, where the language or library enforces the pattern instead of leaving it to your discipline. ## What join does not do - **It does not stop the thread.** Join is passive waiting. If the child loops forever, join waits forever. To end a child early you must cancel cooperatively (a flag, an interrupt-style signal, closing the input it reads) and *then* join to confirm it stopped. - **It does not propagate failures.** If the child throws, most runtimes log or hand the exception to a per-thread failure hook and the thread simply ends; the joiner sees a normal return. Errors must be carried out of the thread explicitly, which is precisely what futures/promises add on top of raw threads. - **It does not compose safely without timeouts.** An unbounded join in a request path converts a stuck worker into a stuck request, then a stuck thread pool, then an outage. Use a timed join: wait up to T, and if it expires, take a deliberate decision (abandon and report, retry, escalate) rather than blocking indefinitely. ## Self-join and cycles A thread joining itself deadlocks by definition — it would have to terminate before it can proceed. More subtly, two threads that join each other deadlock the same way. Join participates in deadlock cycles exactly like a lock does, because it is a wait-for edge in the same dependency graph. ## When you would not join Long-lived background threads — a metrics flusher, a log shipper, a scheduler tick — are not joined at every use; they are joined once, at shutdown, after being asked to stop. And in async models you rarely join threads at all: you await a future, which carries both the value and the error and does not tie up an OS thread while waiting. Join is the primitive; futures and structured-concurrency scopes are the ergonomic layers built over it.