how does locking a reentrant lock again helps when we already have the lock on it?

Question

So , a reentrant lock increments the count by one if the current thread acquires the lock again. what i am unable to understand is why and how that helps or benefits us?

Answer 1

The reason, that a reentrant lock is doing this, is to not lock the same Thread again, that has already acquired this lock.

For example: Let's say you have Thread A that is acquiring your Reentrant Lock A. Than Thread B tries to acquire the Lock A, which will result in Thread B getting blocked (more about the Thread states can be found here). Now, Thread A is trying to (again) acquire the Lock A.

Because the Reentrant lock is now highering its count, Thread A is not getting blocked. Thread A still has access over the Lock and can continue (the locks stores the informations about the depth). If he (sooner or later) releases the Lock, the count will be lowered again, to check if Thread A still need the Lock or not. If the count gets to 0, meaning Thread A has released for every time he has acquired, Thread B will get the access over the Lock.

Without reentrancy, you now would have a deadlock. Why? Because Thread A has the lock and would wait to get it again.

---

Concurrency can be realy complicated, reentrancy helps (just a bit) reducing this complexity.

Answer 2

This helps for the unusual situation when you want to call another method that also requires a lock.

ReentrantLock lock = new ReentrantLock();

public void doSomething() {
    lock.lock();
    try {
        // Something.
    } finally {
        lock.unlock();
    }
}

public void somethingElse () {
    lock.lock();
    try {
        // Something else.
        // We can now call another locking method without risking my lock being released.
        doSomething();
    } finally {
        lock.unlock();
    }
}

Here public can call doSomething and it will acquire the lock, do it's thing and then release the lock when unlock is called.

However, when somethingElse is called and it calls doSomething it just increases the lock count. When doSomething unlocks it does not release the lock, it merely counts the lock-count down, leaving the final unlock in somethingElse to release the lock.

Answer 3

The point of incrementing a count for the lock is to keep track of how many times the thread acquired the lock, so that the lock won't actually be released until the thread indicates readiness to release the lock the same number of times.

The assumption is that commands for locking will be matched with commands for releasing the lock.

Say my code enters Code Section A, which requires the lock.

Then without exiting Code Section A, it enters Code Section B which also requires the same lock. As you note we have the lock, so we needn't block.

But we'll leave Section B, and Section B is written to release the lock when we exit it. (Otherwise code that reaches Section B without already having the lock would never release the lock.)

We're still in Section A, though, so we don't want to really give up the lock yet, or another thread could take it while we're in Section A.

So when we entered Section B we incremented the lock count, which means when we exit Section B we can reduce the count by one and, seeing that it's not back to 0, not release it.

Then when Section A again releases the lock, the count falls back to 0 and that is when we really let the lock go.