Why can I not writeLock after ReadLock?

[Christoph Bartoschek]

Am Samstag 13 November 2010 schrieb Milian Wolff:
> On Saturday 13 November 2010 13:11:50 David Nolden wrote:
> > Acquiring a write-lock while already owning a read-lock is simply not
> > possible. There may be multiple readers at the same time, but only one
> > writer. If multiple readers would request a write-lock at the same
> > time, there would be no way to satisfy it (there may be no other
> > active readers while there is an active writer), thus we simply cannot
> > allow a reader to become a writer without unlocking in between.
> 
> Is there really no way around this? QReadWriteLock seems to support this:
> 
> http://doc.qt.nokia.com/4.7/qreadwritelock.html#lockForWrite
> Locks the lock for writing. This function will block the current thread if
> another thread has locked for reading or writing.
> 
> I.e. I can lockForRead(); and afterwards lockForWrite().
> 
> Just the other way around is not supported:
> http://doc.qt.nokia.com/4.7/qreadwritelock.html#lockForRead
> Locks the lock for reading. This function will block the current thread if
> any thread (including the current) has locked for writing.
> 
> So why can we not do the same? Actually - why are we not using that to
> begin with? Performance issues?
> 
> I do have to confess though that I don't really see how to support it.
> Your point about my patch being bad is right, of course... And
> temporarily decreasing the m_totalReaderRecursion in lockForWrite is not
> possible, is it? That could introduce race conditions, or?
> 
> What about an intermediate step?
> Unlocked
> ReadLocked
> AboutToWriteLock
> WriteLocked

This is what the QReadWriteLock documentation says you are citing:

Like QMutex, a QReadWriteLock can be recursively locked by the same thread 
when constructed in QReadWriteLock::RecursionMode. In such cases, unlock() 
must be called the same number of times lockForWrite() or lockForRead() was 
called. 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).

Christoph