C ++构造函数线程安全

Question

Let's say I have a member variable vector initialised in the constructor, and this vector is read (not written to anywhere else) in several other member functions. Would I need to protect access to the vector (including in the constructor), or is it guaranteed that the object will be fully initialised and flushed to main memory before it's used in other threads?

Let me provide an example:

class A
{
public:
    A();
    void f1();
    void f2();
private:
    std::vector<int> v;
};

A::A()
{
    // do some setup work in v
    v.push_back(1);
}

// called from thread1
void A::f1()
{
    // some readonly work on v
    for (auto i : v) {
        // do something on i
    }
}

// called from thread2
void A::f2()
{
    // more readonly work on v
    if (v.empty()) {
        // do other work
    }
}

Do I need to lock-protect v in A::A() , A::f1() and A::f2() ?

Answer 1

An object is created by a single thread, so you never have to worry about thread safety when running code inside the constructor that touches member variables. However, if you are using static variables within the constructor then you may need to add some form of locking around the access.

There is an edge case where code within a constructor can be called by multiple threads, and this is when you are using either placement new . For example, let's say you've got a buffer somewhere, and you're going to allocate an object into it:

byte buffer[100];
Foo *foo = new (buffer) Foo;

Here, unless you are locking around the call to new then it's possible for two or more constructors to run in parallel as they're running against the same block of memory. However, this is a real specialized edge-case and would require special handling (eg locking around the placement-new construction).

Answer 2

An object is constructed by a single thread. Other threads can access the object only by means of the instance reference. In other words, the object's constructor will have finished its work before other threads call a method. You therefore don't need to implement thread-safe code within a constructor.

Of course, in case another object is passed to the constructor as a parameter, eventual access to that object within the constructor, should be thread-safe.

Answer 3

As stated in the other answers, there is no point in implementing synchronization primitives in the constructer, but that doesn't mean you can't have a race , if you don't synchronize externally:

std::atomic<A*> g_ptr = nullptr;

void threadFun1() {
    g_ptr.store(new A{}, std::memory_order_relaxed);
}

void threadFun2() {
    A* l_ptr = nullptr;
    while (l_ptr == nullptr) {
        l_ptr = g_ptr.load(std::memory_order_relaxed);      
    }
    l_ptr->f1();
}

In above code, you have a data race between the constructor of A and f1 . The problem is that - without synchonization - from the point of view of thread2, g_ptr might be written before the object is completely constructed.

However, there is nothing you can do inside the constructor to prevent this kind of race. Instead you have to use external means of synchronization, like using non-relaxed memory ordering for the atomic load and store operations or starting thread2 from within thread1 after the global variable is set.

Answer 4

Take this code example below:

model.h

namespace Stackoverflow {
    class Model {
    public:
        Model();
        ~Model();

        std::vector<int> *integers() const { return _integers.get(); }; // read only
    private:
        std::unique_ptr<std::vector<int>> _integers; // registered before constructor
    };
}

model.cpp

Stackoverflow::Model::Model() {
    _integers = std::make_unique<std::vector<int>>(); // initialized
}

Stackoverflow::Model::~Model() {
    _integers.release();
}

The private member "_integers" will be registered but not initialized until the constructor is being called by the caller.

Stackoverflow::Model stackoverflow;

When another thread want to access this vector, call the getter.

auto *vector = stackoverflow.integers();

The member will be fully initialized when the caller is actually asking for the vector.