2

I was checking out the LinkedBlockingQueue source code, and came across the signalNotEmpty method:


private final ReentrantLock takeLock = new ReentrantLock();

// more variable instantiations...

/**
 * Signals a waiting take. Called only from put/offer (which do not
 * otherwise ordinarily lock takeLock.)
 */
private void signalNotEmpty() {
    final ReentrantLock takeLock = this.takeLock; // why do this?
    takeLock.lock();
    try {
        notEmpty.signal();
    } finally {
        takeLock.unlock();
    }
}

Most of the other methods in this class take the same approach with re-defining takeLock or putLock before locking the ReentrantLock and I have absolutely no idea why they would do this.

What are the benefits of this approach vs. just locking the instance's locks explicitly?

Matt
  • 667
  • 5
  • 16
  • And [In ArrayBlockingQueue, why copy final member field into local final variable?](https://stackoverflow.com/questions/2785964/). – Slaw May 14 '19 at 15:14
  • That line of code does not redefine `takeLock`, it assigns a value to `takeLock`. "Redefine" means something else. – Solomon Slow May 14 '19 at 18:39

0 Answers0