Sharing Data Safely Between Threads

When a program starts a thread, it hands that thread some work and some data. The work is usually a function, and the data is usually an object the function should operate on. Once the thread is running, a natural question arises: does the thread work on the original object that the main part of the program created, or does it receive its own separate version of that object? The answer determines whether a change made inside the thread is visible back in main, and getting it wrong is one of the most common ways a threaded program produces a result nobody expected.

This article follows a small program that starts two threads and then waits for both of them to finish. You will trace what each thread is responsible for before reading the explanations. The goal is not to memorize every line. The goal is to notice three places where the program decides what a thread will do: the moment each thread object is created, the arguments handed over at that moment, and the point where main waits for the threads to finish. Keep the question above in mind as you trace it.

Start by tracing the program in order. Main creates the first thread object and supplies it with a function named f and with the vector some_vec, which begins as an ordinary object owned by main. Main then creates the second thread object, this time from a function object built from F applied to a second vector, vec2. Finally, main waits for both threads to finish before it continues. Between the two creation moments and the waiting point, each thread runs its own work.

Notice what changes at each of those three decision points. At creation, the program decides which work the thread will execute. At the argument hand-off, it decides what data that work receives. At the wait, it decides when main is allowed to proceed. A wrong value, if one appears, will usually be visible only after the wait, because that is the first point where main can safely look at what the threads produced.

The thread constructor is a variadic template. In plain terms, this means the constructor does not fix how many arguments it takes. It accepts an arbitrary sequence of arguments, so one list can contain a callable followed by whatever values that callable needs. Because the list is read in order, the rule is simple: the first element identifies what the thread should execute, and every element after it is an input that will be supplied to that work.

The constructor does not need to know in advance how many inputs will follow. Whatever sequence is written is accepted, and the first element is always the one treated as the work. This is why a single constructor call can start a thread that needs no inputs, one input, or several inputs, without a separate constructor for each case.

By default, the variadic template treats an argument as a value. That default is fine for small inputs, but a thread that works on a large container usually needs to operate on the original object. The ref() function, which comes from the functional header, tells the template to treat the object as a reference instead. Writing ref(some_vec) inside the constructor's argument list is the explicit signal that the thread should share the object rather than receive its own version of it.

Follow the vector some_vec through the first thread. It starts as an ordinary object in main. The ref() wrapper marks it for the constructor, and the constructor passes it along as the argument to f. Inside f, the parameter refers to the same vector that main created, so the function changes the original rather than a copy. The diagram below contrasts this with the default value treatment, where the thread works on its own version.

The first element of the constructor call is not limited to a plain function name. The second thread in the source program is constructed from F applied to vec2. F is a struct that stores a reference to a vector in a member and defines an application operator. When a thread is constructed from an object like this, the thread runs that object as if it were called. In other words, the thread executes the operator defined in F on the vector stored inside it.

The source makes an important comparison here. If the operator in F and the function f perform the same algorithm, then handing either one to a thread is roughly equivalent. In both cases the compiler is building a function object for the thread to execute. The difference lies in how that object is written, not in what the thread ends up doing. A learner should therefore not treat a function object as a different kind of thread work; it is another way of writing the same kind of work.

When a threaded program produces a wrong value, the place to look first is the point where main waits for the threads. Until main has waited, the worker may still be running, so main cannot know that the object has reached its final state. The sequence below orders the steps of the program so you can see where a result, or a mistake, first becomes visible relative to the waiting point.