Launching and Joining Threads

Concurrent code is hard to read for one simple reason: the lines of a program are written in one order, but the work they describe may run in several places at once. Before learning any vocabulary, it helps to look at a small program that does work on two separate threads. The goal of this article is to answer two questions for any concurrent code you meet: what is the unit of work, and which execution path is actually carrying it out?

The program you will trace defines a plain function f, a function object F, and a function user that launches both and then waits for them. As you read it, try to notice which lines describe work and which lines describe where that work runs.

Read the program in two passes. The first pass looks at the work: f is a function, and F is a function object whose call operator holds its work. The second pass looks at the placement: user() constructs two std::thread objects, and each construction hands one task to its own thread. The two comments in the source are the authoritative description of where each piece of work runs: f() executes in a separate thread, and F()() executes in a separate thread.

The diagram follows the order of the statements, which is the order in which user() executes them. The two launch steps are the points where a task leaves the calling code and becomes a thread. The two join steps are the points where the calling code pauses until a thread is done. Notice that the diagram does not show the work itself in the main thread: the body of f and the body of F run in the worker threads, not in user().

The important word in the definition is concurrently. A computation is not a task merely because it does work; it is a task because it is something that can be run alongside other computations. This is why the program gives each piece of work its own thread rather than calling both functions one after the other in user().

A thread is the system-level representation of a task, and it is created by constructing a std::thread with the task as its argument. Launching a task concurrently therefore means constructing a thread for it. Each launch in user() is one such act: the task is named once, and it is handed to its own thread.

Read the diagram as a relationship, not as a containment hierarchy. A std::thread object is built from a task, and the thread is the way the system sees that task while it runs. Keeping these two ideas apart prevents a common confusion: the task is the work to be done, and the thread is the execution path that carries that work out.

Threads can be waited for using the join() method. In the program, user() calls t1.join(); and then t2.join();, each annotated with the thread it waits for. Joining is how the caller learns that a particular thread has completed its task before the caller goes on.

The diagram shows the calling thread moving through three states. It is running user(), then it is blocked inside t1.join() while t1 works, and then it resumes once t1 has finished. Only after that resumption does the statement t2.join(); begin, which means the wait for t2 starts after the wait for t1 has ended.

When a concurrent program produces an unexpected result, the first question to ask is which execution path ran the line in question. Find the line that launches each task, identify the thread that task was handed to, and then check whether the line that uses the result comes after the matching join(). A join() that has not yet been reached means the caller may not yet have waited for the thread that produces the value.