Why can I not writeLock after ReadLock?
bartoschek at gmx.de
Sat Nov 13 13:50:40 UTC 2010
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:
> 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?
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).
More information about the KDevelop-devel