Why can I not writeLock after ReadLock?

[Milian Wolff]

On Saturday 13 November 2010 14:50:40 Christoph Bartoschek wrote:
> 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).

OK, thanks for clarifying this. I'll live with it then and use 
DeclarationPointers everywhere.

Bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20101113/425863e8/attachment-0001.sig>