Starting Threads with Functions

Imagine you have some data and you want a worker thread to process it. A natural first thought goes like this: if I give the worker a reference to my data, the worker sees my data, and that is all there is to it. Nothing is copied, so nothing is lost, and nothing can go wrong. This belief feels reasonable, and it is exactly the belief this article is designed to correct.

The usual way to think about a function is that you give it arguments and it returns a result. A function object reverses the emphasis a little. The object is a value that carries its own data, and calling it runs the code you defined inside its operator(). Because the object can hold data between its creation and its call, it can remember things that a plain function would need to receive again each time.

This ability to carry data is what makes function objects useful for threads. The source states that a function object can be used to execute code in a separate thread, and that a function object can store references to variables.

A compact struct shows all the pieces a function object needs. Read it as three jobs: a member that holds a reference, a constructor that stores the reference, and the operator that does the work when the object is called. The short illustrative struct below uses those three jobs. It is a teaching sketch written for this article, not the source program itself.

The operator() declaration is the part that turns F into something you can call. The body of that operator is defined elsewhere in the source program. What matters is the shape: the constructor fills the member, and the operator uses it. When code writes obj(), the compiler calls the struct's operator(), which then works on the data the object already carries.

The source program contains both kinds of task side by side. A regular function f takes a reference to a vector as a parameter. A function object F keeps a reference to a vector as a member. Both can do work on the same data, but they receive that data at different moments and in different ways.

Now follow the data through main. Main creates two vectors, some_vec and vec2, and then starts two threads. The first thread runs the regular function f with some_vec, passed by reference. The second thread is started with F{vec2}, a temporary function object whose member refers to vec2. The source comments state that F(vec2)() executes in a separate thread, and that f(some_vec) executes in a separate thread. Each thread is joined back into main before the program finishes.

Read the diagram as a shared path. The function object inside the worker thread leads back to the same vec2 that main still owns. The diagram shows a single shared object reached by two paths, one from main and one from the function object. Nothing in the picture says which path acts first. That missing ordering information is the core of the data race concern.

The reference is captured when the function object is built, but the data is not read at that moment. The worker reads and writes through the member only when operator() runs inside the thread. Between those two points, main may still be running, and the vector may be changed or otherwise touched. The timeline below lays out that gap.

Passing an argument by reference gives a thread access to the original data. Once a task holds a reference to a vector, that task and whoever else holds the same vector are looking at one shared object. If two tasks touch it at the same time, the result depends on timing. This is a data race. The source is clear that the cure is not a cleverer reference. The cure is a different decision about what gets passed.

The before and after views make the design choice concrete. Passing by reference lets a task use the original data, and it introduces the risk that another task reaches that data at the same time. Passing by value means the task receives its own version of the data. The source states that this eliminates the risk of data races.