Question

I have a simple data class that gets called from another class.

Data Class:

class Data
{
public:
    QString getName() const
    {
        return this->mName;
    }

    void setName(AccessData* access, const QString& name)
    {
        this->mName = name;
        access->emitNameChanged(this);
    }
private:
    QString mName;
    QReadWriteLock mLock;
};

And here’s the class I am using to get/set a new name that also handles the locking:

class AccessData : public QObject
{
public:
    QString getName(Data* data)
    {
        QReadLocker lock(&data->mLock);
        return data->getName();
    }

    void setName(Data* data, const QString& name)
    {
        QWriteLocker lock(&data->mLock);
        data->setName(this, name);
    }

    void emitNameChanged(Data* data)
    {
        emit this->nameChanged(data);
    }
signals:
    void nameChanged(AccessData* access, Data* data);
};

What happens is this:
I use the AccessData class to read and write the name of a Data instance. The AccessData class is responsible for locking for read/write. However, the Data class as you can see, in it’s setName() method calls back the AccessData instance to properly emit a signal about the change. NOTE: This is just pseudo code, in reality it is more complex that’s why the Data class needs to be able to emit signals through it’s caller.

And here’s the problem:

Say I have an instance of “Data” called “d”: Data* d;
I am now using an “AccessData” instance “a” to change the name: a->setName(d, “new name”);
At the same time, I am conncected to the nameChanged() signal with this code:

...
void nameChanged(AccessData* access, Data* data)
{
    // Read the new name
    QString newName = access->getName();
}

And here’s the issue:

1. Calling a->setName(d, “new name”)
2. “d” is now locked by “a” (Write lock)
3. “d” emits a signal about the name change though still locked
4. My method connected to the nameChanged signal tries to access getName()
5. This will cause another QReadLock issued which simply results in a deadlock

What can I do to properly handle this? There’s two things that came up to me:

1. Emit the signal delayed (aka non-blocking) to get it into the loop.
   This is NOT what I want because I want the signals to be pushed immediately.

2. Move the lock/unlock stuff within the Data class and first unlock, then emit the signal.
   This is NOT what I want because I want to keep the Data class completely free from locking stuff.

Any idea? Do I have a miss conception?

thanks a lot
Alex

Answer 1

You need to make your mind about what the objects in your model represent. The philosophy of Data is suspicious. It owns the lock (has-a composition), but you don’t want it to be self-lockable. If Data is meant to be a simple data wrapper, then it shouldn’t own the lock. So either allow it to handle its own lock (and then you can unlock before emiting), or move the lock and the emitting too away from Data to AccessData.

If for some reason you want to keep the presented design, you can “solve” this with initializing mLock as QReadWriteLock::Recursive. Then the same thread can lock it multiple times over – given that you still call an equivalent amount of unlock(). But my personal experience is that reentrant locking is a sure sign of runaway/misunderstood call flow and a creeping misconcept which will bite back hard. While i do read about theoretical concepts which supposedly cannot be solved without reentrant locks, i still have to see one practically unavoidable.