为什么在ReentrantReadAndWriteLock中，readLock（）应该在writeLock.lock（）之前解锁？(Why in ReentrantReadWriteLock, should the readLock() be unlocked before writeLock().lock()?)

 从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();
}
 
 这看起来好多了，也是更安全的方式来处理锁定，不是吗？ 
 
 有人可以解释为什么这个奇怪的实现？ 谢谢。 

From the ReentrantReadWriteLock class 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();
}
 
Why must we release the read lock before acquiring the write lock as written in the comment? If the current thread holds the read lock, then it should be allowed to acquire the write lock when other threads are not reading anymore, regardless of whether the current thread also holds the read lock. This is the behavior I would expect.
 
I would expect the lock upgrade at lines 5 and 6 and the lock downgrade at lines 14 and 15 to be done internally in the ReentrantReadWriteLock class. Why is that not possible?
 
In other words, I would expect the code to work fine like this:
 
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();
}
 
This looks like a much better and safer way to handle locking, doesn't it?
 
Can somebody explain the reason for this weird implementation? Thanks.

原文：https://stackoverflow.com/questions/16901640