Directly from this web site, I came across the following description about creating object thread safety.
Warning: When constructing an object that will b
As the thread scheduler can stop execution of a thread at any time (even half-way through a high level instruction like instances.push_back(this)
) and switch to executing a different thread, unexpected behaviour can happen if you don't synchronize parallel access to objects.
Look at the code below:
#include <vector>
#include <thread>
#include <memory>
#include <iostream>
struct A {
std::vector<A*> instances;
A() { instances.push_back(this); }
void printSize() { std::cout << instances.size() << std::endl; }
};
int main() {
std::unique_ptr<A> a; // Initialized to nullptr.
std::thread t1([&a] { a.reset(new A()); }); // Construct new A.
std::thread t2([&a] { a->printSize(); }); // Use A. This will fail if t1 don't happen to finish before.
t1.join();
t2.join();
}
As the access to a
in main()
-function is not synchronized execution will fail every once in a while.
This happens when execution of thread t1
is halted before finishing construction of the object A
and thread t2
is executed instead. This results in thread t2
trying to access a unique_ptr<A>
containing a nullptr
.
You just have to make sure, that even, when one thread hasn't initialized the Object, no Thread will access it (and get a NullpointerException).
In this case, it would happen in the constructor (I suppose), but another thread could access that very object between its add to the list and the end of the constructor.