Reentrant Lock Queries

[Vaibhav Gargs]

I am learning about Reentrant Lock in Java. I have certain queries related to this:

1. In Reentrant Locks, we can call lock() method multiple times and then need to call unlock() method same number of times. I am unable to understand if I call the lock() method first, I have got the lock, then what is the use of calling lock() method again?

2. In synchroinzed block/methods, we get the lock on object/class depending upon the object. But, in case of Lock API, when we say that we have got the lock, then what is this lock actually?

3. In Reentrant Lock, we have tryLock() method, so, if it gets the lock by calling tryLock(), then it would enter that piece of code, otherwise, will continue with other piece of execution. I am just wondering if I need to continue with other piece of code, then why would I need to the lock at first place itself?

Please share your inputs.

[Henry Wong]

Vaibhav Gargs wrote:
1. In Reentrant Locks, we can call lock() method multiple times and then need to call unlock() method same number of times. I am unable to understand if I call the lock() method first, I have got the lock, then what is the use of calling lock() method again?

I think you are asking the wrong question. The question should be, what would be the advantage of allowing the ownership of the lock more than once?

Example one. You have two methods of a class. Both methods use the same lock -- as they protect the same data. Now, you need to change the code so that one method calls the other method. Allowing re-entrance means that you don't need to worry about deadlock, because the same thread is trying to obtain the same lock twice, which will happen when one method calls the other method.

Example two. What about the case of recursive methods?

Henry

[Henry Wong]

Vaibhav Gargs wrote:
2. In synchroinzed block/methods, we get the lock on object/class depending upon the object. But, in case of Lock API, when we say that we have got the lock, then what is this lock actually?

Well, first, what does "get the lock on object/class depending upon the object" even mean? Synchronization, which when successful, simply gets lock ownership. Or means that some internal data structure is changed to state that the lock is owned.  Later, when you try to synchronize from another thread, that thread will block, until the first thread frees the lock (change the state to not owned).

The same goes for the reentrant lock class. When a thread owns the lock, some internal data structure is changed, to state that the lock is owned. Later, when a different thread calls the lock() method, that thread will block, until the first thread frees the lock.

In both cases, a lock is just a piece of memory that holds information which can be used to determine which thread owns the lock.

Henry

[Henry Wong]

Vaibhav Gargs wrote:
3. In Reentrant Lock, we have tryLock() method, so, if it gets the lock by calling tryLock(), then it would enter that piece of code, otherwise, will continue with other piece of execution. I am just wondering if I need to continue with other piece of code, then why would I need to the lock at first place itself?

If both code paths are identical, then, yes, I agree -- there is no real need to get the lock in the first place...

However, what if the other path is a slower, backup path? A code path that uses a different locking mechanism. A code path that is preferred not to be taken if possible.  Or what if the other path is a collision path? A path that is taken to clean up the mess that may have been caused when two threads are trying to execute at the same time? etc.

Henry

[Campbell Ritchie]

Vaibhav Gargs wrote:. . . . we get the lock on object/class depending upon the object. . . . .

Because Java® was designed from the wor‍d “go” with concurrency in mind, any object can be used as a lock. In the case of synchronised instance methods or blocks, this is often used as the object to lock, and in the case of static methods, the corresponding Class object, not simply the class, is used. It is likely that you would use Foo.class to obtain the Class object. When you enter a synchronised method, it is likely that there is one bit in the lock object which is set, and the thread takes ownership of that lock. When the synchronised code is finished, the thread relinquishes ownership and unsets that bit.

But you know all that already, don't you?

[Henry Wong]

Campbell Ritchie wrote:In the case of synchronised instance methods or blocks, this is often used as the object to lock, and in the case of static methods, the corresponding Class object, not simply the class, is used. It is likely that you would use Foo.class to obtain the Class object. When you enter a synchronised method, it is likely that there is one bit in the lock object which is set, and the thread takes ownership of that lock. When the synchronised code is finished, the thread relinquishes ownership and unsets that bit.

Synchronized methods (and blocks) are also re-entrant, so, it may be more than a bit -- as something has to track the count of lock grabs.

Henry

[Campbell Ritchie]

Henry Wong wrote:. . .  has to track the count of lock grabs.

Henry

Could be in the lock object (as it is in ReentrantLock) or the thread; sounds like something implementation‑dependent.