Why can I not writeLock after ReadLock?

[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

?

> In C++, I've worked around this problem by using DUChainPointer. You
> could do the same. In long-term, we should find a better solution of
> course, for example by using more indirect references like
> DeclarationId.
> 
> Another maybe simpler work-around would be using UrlParseLock or
> something similar to prevent the file which contains the declaration
> from being re-parsed while holding the reference. Maybe this is the
> way to go, due to efficiency.

Imo this is all not what we want. We don't want the declaration to get invalid 
at all in that period and the above would make sure this works as intended.


-- 
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/7ec3b48e/attachment.sig>