为什么在ReentrantReadAndWriteLock中,readLock()应该在writeLock.lock()之前解锁？

Question

从ReentrantReadAndWriteLock类javadoc:

void processCachedData() {
  rwl.readLock().lock();
  if (!cacheValid) {
     // Must release read lock before acquiring write lock
5:   rwl.readLock().unlock();
6:   rwl.writeLock().lock();
     // Recheck state because another thread might have acquired
     //   write lock and changed state before we did.
     if (!cacheValid) {
       data = ...
       cacheValid = true;
     }
     // Downgrade by acquiring read lock before releasing write lock
14:  rwl.readLock().lock();
15:  rwl.writeLock().unlock(); // Unlock write, still hold read
  }

  use(data);
  rwl.readLock().unlock();
}

为什么我们必须在获取注释中写入的写锁之前释放读锁？如果当前线程持有读锁定,那么当其他线程不再读取时,应该允许它获取写锁定,无论当前线程是否还保持读锁定.这是我期望的行为.最终在第4行和第5行锁定升级并在第14行和第15行锁定降级我希望在ReentrantReadAndWriteLock类内部完成.为什么那是不可能的？

换句话说,我希望代码能够正常工作:

void processCachedData() {
  rwl.readLock().lock();
  if (!cacheValid) {
     // The readlock is upgraded to writeLock when other threads 
     // release their readlocks.
     rwl.writeLock().lock();
     // no need to recheck: other threads can't have acquired  
     // the write lock since this thread still holds also the readLock!!!
     if (!cacheValid) {  
       data = ...
       cacheValid = true;
     }
     // Downgrade by acquiring read lock before releasing write lock
     rwl.writeLock().unlock(); // Unlock write, still hold read
  }

  use(data);
  rwl.readLock().unlock();
}

这看起来更好,更安全的方式来处理锁定,不是吗？

有人可以解释为什么这个奇怪的实现？谢谢.

Answer 1

将读锁升级到写锁的问题是,如果两个线程同时尝试执行此操作,则可能导致死锁.请考虑以下顺序:

1. 线程A:获取读锁定
2. 线程B:获取读锁定(请注意,两个线程现在共享读锁定).
3. 线程A:尝试获取写锁定(块B作为线程B持有读锁定)
4. 线程B:尝试获取写锁定(当线程A保持读锁定时的块)

现在有一个僵局.线程A或B都不能继续,也不会释放读锁定.

Answer 2

Javadoc明确指出不能将读锁升级到写锁.的原因是,因为它可以创建一个死锁.

• 线程1获取读锁定
• 线程2获取读锁定
• 线程1要求升级锁写入
• 线程2要求升级锁写入

两个线程现在正在等待......永远.