QReadWriteLock recursion

Question

I'm using QReadWriteLock in recursive mode.

This code doesn't by itself make sense, but the issues I have arise from here:

lock->lockForWrite();
lock->lockForRead();

lockForRead is blocked. Note that this is in recursive mode.

The way i see it is that Write is a "superior" lock, it allows me to read and write to the protected data, where Read lock only allows reading.

Also, i think that write lock should not be blocked if the only reader is the same one asking for the write lock.

I can see from the qreadwritelock.cpp source codes that there is no attempt to make it work like what i would like. So it's not a bug, but a feature I find missing.

My question is this, should this kind of recursion be allowed? Are there any problems that arise from this kind of implementation and what would they be?

Answer 1

From QReadWriteLock docs:

Note that the lock type cannot be changed when trying to lock recursively, i.e. it is not possible to lock for reading in a thread that already has locked for writing (and vice versa).

So, like you say, it's just the way it works. I personally can't see how allowing reads on the same thread as write locked item would cause problems, but perhaps it requires an inefficient lock implementation?

You could try asking on the QT forums but I doubt you'll get a definitive answer. Why don't you take the QT source as a starter and have a go at implementing yourself if it's something you need. Writing synchronisation objects can be tricky, but it's a good learning exercise.

Answer 2

I found this question while searching for the same functionality myself. While thinking about implementing this on my own, I realized that there definitely is a problem arising doing so:

So you want to upgrade your lock from shared (read) to exclusive (write). Doing

lock->unlock();
lock->lockForWrite();

is not what you want, since you want no other thread to gain the write lock right after the current thread released the read lock. But if there Was a

lock->changeModus(WRITE);

or something like that, you will create a deadlock. To gain a write lock, the lock blocks until all current read locks are released. So here, multiple threads will block waiting for each other.