ReentrantLock
The class ReentrantLock is a mutual exclusion lock with the same basic behavior as the implicit monitors accessed via the synchronized keyword but with extended capabilities. As the name suggests this lock implements reentrant characteristics just as implicit monitors.
Let's see how the above sample looks like using ReentrantLock
Toni Lane wrote:
A synchronized keyword guarantees atomicity and visibility and it has to operate on two things.
1- A thread. (The calling thread)
2- An object. (The monitor object)
Henry Wong wrote:
Toni Lane wrote:
A synchronized keyword guarantees atomicity and visibility and it has to operate on two things.
1- A thread. (The calling thread)
2- An object. (The monitor object)
Question. What "atomicity and visibility" guarantees are you referring to? Method calls? Access to instance variables?
Simply, there are *no* method or variable guarantees, with owning a synchronization lock on an object. The only guarantee is that only one thread can own the lock (on the object) at a time. Synchronization locks are cooperative. It is the developer's responsibility to take the "only one thread can own the lock" guarantee, and make that into visibility and atomicity guarantees.
Henry
Stephan van Hulst wrote:Only one thread can lock an instance of a lock at a time.
That means that if you lock an instance of a lock, other threads can still lock other locks. The same thread can lock a lock twice, and it won't block. A thread locking a lock that has already been locked by another, will block until the other thread has unlocked the lock.
Surely that means, A thread trying to lock ... because a thread has to wait until the other thread has finished and releases the lock first.Stephan van Hulst wrote:. . . The same thread can lock a lock twice, and it won't block. A thread locking a lock that has already been locked by another, will block until the other thread has unlocked the lock.
Campbell Ritchie wrote:Surely that means, A thread trying to lock ... because a thread has to wait until the other thread has finished and releases the lock first.
Campbell Ritchie wrote:
Surely that means, A thread trying to lock ... because a thread has to wait until the other thread has finished and releases the lock first.Stephan van Hulst wrote:. . . The same thread can lock a lock twice, and it won't block. A thread locking a lock that has already been locked by another, will block until the other thread has unlocked the lock.
There are limits to how often a Lock can be locked. You get problems with more than 2147483647 locks on the same object I take it OP knows to use finally blocks for all unlock() calls.
Brian Goetz in Java Concurrency in Practice strongly recommends the following technique for ensuring that a lock is released. It uses a try..finally style; this ensures that no matter what happens during the time the lock is held, it will eventually be unlocked. Even if an unexpected RuntimeException is thrown, the lock will still be released.
The government thinks you are too stupid to make your own lightbulb choices. But this tiny ad thinks you are smart:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
|