Why can I not writeLock after ReadLock?
mail at milianw.de
Sat Nov 13 12:57:40 UTC 2010
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:
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:
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?
> 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
> 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.
mail at milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the KDevelop-devel