What does "reentrant" mean in concurrency?

[Anil Philip]

In English, I believe that "reentrant" means "to enter in again".
How does this relate to concurrency and threads for instance ReentrantReadWriteLock?

https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/concurrent/locks/ReentrantReadWriteLock.ReadLock.html#lock()

[Paul Clapham]

Reading the documentation wasn't all that helpful to me. So... "reentrant lock" in Google... Binary Semaphore vs Reentrant Lock... right. What it says in section 3.

[Stephan van Hulst]

A critical section that is protected by a reentrant lock can be reentered by the same thread.

This includes entering a different critical section that is protected by the same lock:

void doProtectedThing() {
  lock.lock();

  try {
    i++;
    doAnotherProtectedThing();
  }

  finally {
    lock.unlock();
  }
}

void doAnotherProtectedThing() {
  lock.lock();

  try {
    j++;
  }

  finally {
    lock.unlock();
  }
}

If lock weren't reentrant, a thread executing doProtectedThing() would block when it reached the call to doAnotherProtectedThing(), leading to deadlock.

[Anil Philip]

Stephan van Hulst wrote:A critical section that is protected by a reentrant lock can be reentered by the same thread.

This includes entering a different critical section that is protected by the same lock:

Thank you for the explanation.
From reading it, I understand that the Reentrant Lock knows that the thread that is trying to access it again already holds it and so it will allow it to execute through the "another protected section"?
As I understand, this will not guarantee against deadlock when there are different locks - in the case where "another protected thing" was held by a different lock - please correct me if I am mistaken.

[Stephan van Hulst]

That is correct.

[Anil Philip]

Stephan van Hulst wrote:That is correct.

thanks

[Mike Simmons]

One minor addition: being reentrant also includes handling the unlocks correctly.  Specifically, if we modify Stephan's example to add something else after the call to doAnotherProtectedThing();

void doProtectedThing() {
  lock.lock();
 
  try {
    i++;
    doAnotherProtectedThing();
    k++
  }
 
  finally {
    lock.unlock();
  }
}

That call to k++ is also protected by the lock, even though the doAnotherProtected() method called unlock on the same lock.  Basically, a reentrant lock counts how many times it has been locked, and how many times it has been unlocked.  And it only really unlocks when the number of unlock calls is equal to the number of lock calls.  So you can have an arbitrary number of nested lock / unlock pairs, and the lock will not be released until the first, outermost pair of lock/unlock calls is finally exited.

This also makes it even more important to make sure that each unlock occurs in a finally blocks, from a try started immediately after the lock() was called.  Because if you ever fail to unlock properly from a bunch of nested calls like that, it can be less than obvious where the problem is.

[Anil Philip]

Mike Simmons wrote:
That call to k++ is also protected by the lock, even though the doAnotherProtected() method called unlock on the same lock.  Basically, a reentrant lock counts how many times it has been locked, and how many times it has been unlocked.  And it only really unlocks when the number of unlock calls is equal to the number of lock calls.  So you can have an arbitrary number of nested lock / unlock pairs, and the lock will not be released until the first, outermost pair of lock/unlock calls is finally exited.

Would it be accurate to say that a ReentrantReadWriteLock is like a cyclic barrier for one thread whereas a CyclicBarrier is for multiple threads? (though I don't know about nesting critical sections for CyclicBarrier).

[Mike Simmons]

Not really.  They are sort of similar in that they both have algorithms involving counting how many times a method has been called, but their use cases are fairly different.

[Campbell Ritchie]

Mike Simmons wrote:. . . a finally blocks, from a try started immediately after the lock() was called. . . . .

If the lock() call is inside the try, and it fails, then the count of unlocks will be greater than the count of locks, and you can rely on something nasty going wrong.

[Peter Rooke]

Not related to Java, but re-entry was (maybe is) a vulnerability with smart contracts that run on blockchains.  
Here's an example showing an exploit in the solidity language which typically runs in the Ethereum virtual machine Reentrancy - Hack Solidity