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?

I'm new to qt , can you tell what do you mean by `recursive mode` ? — Mr.Anubis, Sep 12 '12 at 07:24
that means I can lock the same mutex multiple times from the same thread, lock lock lock and unlock unlock unlock. where in non - recursive mode the second lock would be blocked. — 0xbaadf00d, Sep 13 '12 at 06:11

score 4 · Answer 1 · answered Sep 12 '12 at 07:49

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.

I had a look at it and there was a small issue. To allow Read type locking of already Write locked locks is very easy to implement to the current code. But the hard part is with handling the unlocks, since now I'd have to remember what kind of lock was made last time. Current implementation is a bit hack-ish and doesn't provide an easy platform to do this. I didn't really focus on it, so maybe an efficient solution is not that difficult. — 0xbaadf00d, Sep 13 '12 at 06:14

score 1 · Answer 2 · answered Oct 23 '13 at 09:19

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.

I like that "changeModus" idea. I'm not certain if this would cause a performance issue. I went throught the code once some time ago and I remember thinking of some performance issue, but I cannot remember what it was and thus I have no idea if it would affect this. — 0xbaadf00d, Nov 04 '13 at 10:40

QReadWriteLock recursion

2 Answers2