Win a copy of Microservices in Action this week in the Web Services forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Devaka Cooray
  • Liutauras Vilda
  • Jeanne Boyarsky
Sheriffs:
  • Knute Snortum
  • Junilu Lacar
  • paul wheaton
Saloon Keepers:
  • Ganesh Patekar
  • Frits Walraven
  • Tim Moores
  • Ron McLeod
  • Carey Brown
Bartenders:
  • Stephan van Hulst
  • salvin francis
  • Tim Holloway

Reentrant Lock Queries  RSS feed

 
Ranch Hand
Posts: 370
2
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
author
Posts: 23810
140
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
author
Posts: 23810
140
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
author
Posts: 23810
140
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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

 
Marshal
Posts: 61805
193
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
author
Posts: 23810
140
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Marshal
Posts: 61805
193
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.
 
Don't get me started about those stupid light bulbs.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!