C++、Qt - 锁定保护和返回对 object 的不可分配引用的安全性

Question

Suppose the following scenario:

I have implemented my own QReadWriteLockGuard:

class QReadWriteLockGuard {
public:
    explicit QReadWriteLockGuard(QReadWriteLock & m) : m(m) {m.lockForRead();}
    ~QReadWriteLockGuard() {m.unlock();}

    QReadWriteLockGuard(QReadWriteLockGuard const &) = delete;
    void operator=(QReadWriteLockGuard &) = delete;

private:
    QReadWriteLock & m;
};

I have a "manager" object A, which holds an instance of object B.

Object A has a method get_b:

const B& A::get_b() const
{
    QReadWriteLockGuard(_b_lock);
    return *_b;
}

Now, B of course has its substructure: attributes, public methods etc. Assume that another thread can rewrite the contents of _b at any time, or even delete them, if they are pointers. However, it will call _b_lock.lockForWrite() first.

Assume that B is not assignable (private assignment and copy operators). Is it safe to do this:

A_instance.get_b().get_vector().at(i).do_stuff() ?

In other words, will the ReadWrite lock be unlocked before or after execution of do_stuff() ? Or is it perhaps undefined?

Answer 1

A const reference does not mean that the object is const , only that you cannot modify the object via that reference. If one thread has that const reference and reads it and another thread writes to the same object (via a non-const reference) then you have a data race.

Your QReadWriteLockGuard releases the lock when A::get_b() returns, so it won't help.

For this line:

A_instance.get_b().get_vector().at(i).do_stuff();

Consider that it is more or less equivalent to

const B& b = A_instance.get_b();
b.get_vector().at(i).do_stuff();

and after the first line you already released the lock.