Call a method with thread in C++

Here’s one way to solve the immediate problems I can find in your code. I also added std:: everywhere because using namespace std is bad.

std::vector<series> ts; ts.reserve(csv.size()); // [1] int col = 0; std::vector<std::thread> th; th.reserve(csv.size()); // [1a] optional for (unsigned int i = 0; i != csv.size(); ++i) { ts.push_back(series(csv[i])); th.emplace_back(&series::loaddata, &ts[i], col); // [2] } // Lots of other code could be executed here. Joining only has to happen // at *some* point after creating the threads. // [3] for (auto& thread : th) { thread.join(); } 

[2]

Let’s start here because this is the most straight forward problem. The pattern to call a member function with std::thread is:

std::thread(ptr-to-member-func, ptr-to-object, member-func-args...); 

Essentially you have to provide the object that will become this when executing loaddata(). And it’s called the “this pointer” for a reason. ;)

Also emplace_back() is a forwarding function that only takes the constructor arguments of the object you want to put into the vector. Explicitely constructing std::thread(...) here defeats the purpose.

[3]

This one is also simple. You have to make sure that the threads can do all their work and exit properly. That means calling join() at some point, which will block until the thread is done. That’s especially important if you still have threads running when you want to exit your whole program.

Note that calling join() inside the for loop like in ΔλЛ’s answer won’t work. If you do it like that you’ll create a single thread, wait for it to finish, and then continue with the next thread. That’s a convoluted way of doing single-threaded execution.

[1]

A small reminder on how vector (and basically all other std containers) works. It allocates a block of memory and uses that for the items you push_back(). When it runs out of space it allocates a new – larger – block of memory, copies or moves the existing items there and continues to push_back(). Reallocation means that all references and pointers to the items as well as all iterators into the vector are invalidated.

Which brings us back to [2]. There you pass a pointer to an item in the vector ts. But ts will have to re-allocate at some point during the loop (at least that’s what you have to assume) – leaving the threads with dangling pointers. That’s classic undefined behaviour.

There are multiple ways to solve that problem. [1] shows a very simple one that works nicely if you know in advance how large the vector will become. reserve() allocates enough space for the given number of elements, which prevents reallocation. Your pointers stay valid.

Another solution is to introduce an additional indirection: usually by allocating the items on the heap and storing pointers in the vector. Like this:

std::vector<std::unique_ptr<series>> ts; for (...) { ts.push_back(new series(csv[i])); // In C++14 you would use std::make_unique instead of a raw new. th.emplace_back( &series::loaddata, ts[i].get(), // notice the difference col); } 

Now the vector can reallocate as much as it likes. It only needs to copy some pointers to its new memory block. The addresses of the actual series objects are not affected anymore.

[1a]

Why did I say this is optional? th is going to reallocate the same as ts. However, you don’t hold on to any refs or pointers to your thread objects. It doesn’t matter if they get invalidated. And std::thread is movable, i.e. it will survive reallocation just fine. On the other hand memory allocation is a potentially expensive operation and it’s trivial to avoid in this case.

P.S.

Have a look at std::async for a more high-level approach to concurrency. Threads are a very low-level construct. If you can, better avoid dealing with them directly.