Following is just a simple program to test using two threads to insert a hash table. For test no lock is used.
#include
#include
The error is very cryptic indeed, but the problem is that thread_add
takes its first parameter by reference, but you're passing it by value. This causes the functor type to be deduced wrong. If you want to pass something actually by reference to a functor like std::bind
or the main function of a std::thread
, you need to use a reference wrapper (std::ref
):
void test()
{
// ...
t[0] = thread(thread_add, std::ref(ht), 0, 9);
t[1] = thread(thread_add, std::ref(ht), 10, 19);
// ...
}
[Live example]
I could compile your code successfully with MSVC2013. However, thread()
works passing copies of its argument to the new thread. This means that if your code would compile on your compiler, each thread wourd run with its own copy of ht
, so that at the end, main
's ht
would be empty.
GCC doesn't compile with this weird message. You can get rid of it by using the reference wraper with thread:
t[0] = thread(thread_add, std::ref(ht), 0, 9);
t[1] = thread(thread_add, std::ref(ht), 10, 19);
This will compile succesfully. And each reference used by the threads would refer to the same object.
However, there are high chances that you'll get some runtime error or unexpected results. This is because two threads are concurently trying to insert into ht
. But unordered_map
is not thread safe, so these racing conditions might cause ht
to reach an unstable state (i.e. UB, i.e. potential segfault).
To make it running properly, you have to protect your concurent accesses:
#include <mutex>
...
mutex mtx; // to protect against concurent access
void thread_add(unordered_map<int, int>& ht, int from, int to)
{
for (int i = from; i <= to; ++i) {
std::lock_guard<std::mutex> lck(mtx); // protect statements until end of block agains concurent access
ht.insert(unordered_map<int, int>::value_type(i, 0));
}
}