• 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
  • Liutauras Vilda
  • Bear Bibeault
  • Jeanne Boyarsky
  • Tim Cooke
Sheriffs:
  • Knute Snortum
  • Junilu Lacar
  • Devaka Cooray
Saloon Keepers:
  • Ganesh Patekar
  • Tim Moores
  • Carey Brown
  • Stephan van Hulst
  • salvin francis
Bartenders:
  • Ron McLeod
  • Frits Walraven
  • Pete Letkeman

ReentrantLocks in Java  RSS feed

 
Ranch Hand
Posts: 364
2
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am going through the link: https://www.geeksforgeeks.org/reentrant-lock-java/ to know more about Reentrant Locks. It is mentioned - "As the name says, ReentrantLock allow threads to enter into lock on a resource more than once. When the thread first enters into lock, a hold count is set to one. Before unlocking the thread can re-enter into lock again and every time hold count is incremented by one. For every unlock request, hold count is decremented by one and when hold count is 0, the resource is unlocked."

I am just wondering why someone would take the lock more than once?

And, in case of reentrant lock, we are not calling methods on any object instead we call lock.lock(), so, actually on which thing this lock is acquired? Is this same thing as synchronized locks?
 
Marshal
Posts: 60806
190
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Vaibhav Gargs wrote:. . . "As the name says, ReentrantLock allow threads to enter into lock on a resource more than once. . . . ."

I am just wondering why someone would take the lock more than once?

In that code, although the assignment in line 9 is atomic, you do not know whether a second thread will read the new value or the old value of i. So you use a Lock object to synchronise the two methods. Note that the lock() call doesn't go in a try, but the unlock() call has to be in a finally.That's a very simple and naïve example, but if you are trying to call setI(), and a different thread attempts to use getI(), that second thread cannot acquire the lock on line 24 until after the lock has been released on line 18. The same would happen if a thread executes the getI() method. If you are using beginners' code and un‑comment line 14, the thread executing that code already holds the lock. When it reaches line 24, it can lock the lock again with a count of 2. You should find it easy to work out that, by the time the setI() method completes on line 18, the lock count is back to 0.

. . . we are not calling methods on any object . . .

Yes, you are. The Lock reference points to an instance of the ReentrantLock class, so that is an object. You are not using its intrinsic lock but explicitly counting how often it has been locked.

Is this same thing as synchronized locks?

It is used instead of the keyword synchronized.
 
Vaibhav Gargs
Ranch Hand
Posts: 364
2
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:That's a very simple and naïve example, but if you are trying to call setI(), and a different thread attempts to use getI(), that second thread cannot acquire the lock on line 24 until after the lock has been released on line 18. The same would happen if a thread executes the getI() method. If you are using beginners' code and un‑comment line 14, the thread executing that code already holds the lock. When it reaches line 24, it can lock the lock again with a count of 2. You should find it easy to work out that, by the time the setI() method completes on line 18, the lock count is back to 0.



We can achieve the same behavior by synchronizing both the methods: getI and setI so that it would allow only one thread to enter the synchronized context. Isn't it? How the explicit locking differs from synchronized in this context?
 
Saloon Keeper
Posts: 4864
117
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

I am just wondering why someone would take the lock more than once?


In multi-threaded code (like a web app) often multiple users run the same code at the same time.

We can achieve the same behavior by synchronizing both the methods: getI and setI so that it would allow only one thread to enter the synchronized context.


As you said, synchronizing only allows a single thread to run the code - that's generally not what you want in a multi-threaded application that services multiple users simultaneously.
 
Campbell Ritchie
Marshal
Posts: 60806
190
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tim Moores wrote:. . . As you said, synchronizing only allows a single thread to run the code . . .

Good point; it might be possible to have different locks for different methods. That is what the read‑write locks are all about.
 
author
Sheriff
Posts: 23603
138
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:
We can achieve the same behavior by synchronizing both the methods: getI and setI so that it would allow only one thread to enter the synchronized context. Isn't it? How the explicit locking differs from synchronized in this context?



The ReentrantLock class was added with Java 5, as a replacement for the synchronized keyword. It actually can be used to do everything that the synchronized keyword can do.

The reverse is not true however. The synchronize keyword, can't be used to try a lock, doesn't have any fairness controls, and doesn't support more than one condition variable per lock.

Henry
 
Sheriff
Posts: 23714
50
Eclipse IDE Firefox Browser MySQL Database
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I merged your stuff with the following thread. I hope that is okay by you.
 
Vaibhav Gargs
Ranch Hand
Posts: 364
2
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We can achieve synchronization using two approaches : synchronized keyword and locks interfaces? Which one is preferred in which scenario and why?
 
Campbell Ritchie
Marshal
Posts: 60806
190
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You asked about locks a few weeks ago; you  will have seen that Lock objects ive you much more flexibility and versatility than the synchronized keyword. I think you would prefer locks all the time.
 
Henry Wong
author
Sheriff
Posts: 23603
138
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:You asked about locks a few weeks ago



Agreed... https://coderanch.com/t/698053/java/ReentrantLocks-Java

Henry
 
Vaibhav Gargs
Ranch Hand
Posts: 364
2
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Campbell and Henry. I am sorry as I was looking for my older post but couldn't locate it due to title as Reentrant Locks. I will continue with the older thread, can you please remove this thread as duplicate.
 
Vaibhav Gargs
Ranch Hand
Posts: 364
2
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Paul Clapham wrote:Vaibhav Gargs,
I have merged your topic into this topic. I hope that helps.



Thanks Paul. It helps.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!