File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

wait() releases all locks?

 
Miki Muzsi
Ranch Hand
Posts: 120
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I just want to make sure I don't make any confusions. So far I thought (I knew) taht a call: a.wait() releases the lock on object a. But if I understand correctly (from one of the questions of master exams for Kathy&Bert + JLS 17.14), a call to a wait() releases ALL the locks the Thread had acquired.
Questions:
1. Does this means we can not have dead locks using wait? (Only if we use sleep())?
2. Does the a.wait() release also the class lock A? Suppose the a.wait() call is done from a synchronized method of A (so the class A lock is also acquired by enterning a static synchronized method).
e.g.
class A {
static synchronized foo(A a) {
}
}
// thread blcok
synchronize(a) {
}
 
Miki Muzsi
Ranch Hand
Posts: 120
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sorry the above example was not complet (by mistake I have posted):
class A {
static synchronized foo(A a) {
synchronize(a) {
a.wait()
}
}
}
// thread
A a = new A();
A.foo(a);
 
Marlene Miller
Ranch Hand
Posts: 1392
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This program shows that wait does NOT cause a thread to release ALL of its locks.

Thread-1 holds locka= true
Thread-1 holds lockb= true
main attempting to acquire locka
Thread-1 is added to the wait set of lockb, but does not release locka. The main thread cannot acquire locka.
[ July 07, 2003: Message edited by: Marlene Miller ]
 
Marlene Miller
Ranch Hand
Posts: 1392
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In the program above, change lockb.wait to locka.wait.
Thread-1 holds locka= true
Thread-1 holds lockb= true
main attempting to acquire locka
main attempting to acquire lockb
Thread-1 is added to the wait set of locka, but does not release lockb. The main thread acquires locka, but cannot acquire lockb.
[ July 07, 2003: Message edited by: Marlene Miller ]
 
Marlene Miller
Ranch Hand
Posts: 1392
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
1. Does this means we can not have dead locks using wait? (Only if we use sleep())?

A deadlock can occur without any thread invoking sleep.
 
Miki Muzsi
Ranch Hand
Posts: 120
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Marlene. I've tried and indeed it works . But then I'm really confused about JLS 17.14 (Wait Sets and Notification") where it talks about N UNLOCK actions in order to relinquish the lock (when wait is invoked), and N-1 additional LOCKS when it returns from wait().
And also Kathy&Bert 's tests, talk about unlocks in the tests (master exam) and the book (in the book is true only in one table where describes the several thread related methods).
I hope I will not get something similar tomorrow on the exam
Miki
 
Alton Hernandez
Ranch Hand
Posts: 443
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

So the JVM maintains a count on the no. of times the object had been locked. But take note that only the thread that originally holds the lock can do this.
I believe what the JLS is saying is that when you invoked wait() after the object had been locked N times, the thread will release all that lock(N UNLOCK actions). But once it returns from wait(), it will get hold the same no. of locks it had before (N-1 additional LOCKS).
Why N-1? When the thread moves from the wait to the running state, it will get hold of 1 lock of the object. So that means it only needs N-1 to restore the no. of locks it once had.
[ July 08, 2003: Message edited by: Alton Hernandez ]
 
Miki Muzsi
Ranch Hand
Posts: 120
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Alton, thanks. I think I understood your point.
However:
after the object had been locked N times

as far as I know one object has one lock. Once a thread gets the lock, nobody else can get the same lock (on the same object). So why do we talk then about N locks on the same object? Does JVM keeps internally a count, representing the nr of lcoks on the same object? Why is a boolean logic not good enough?
Miki
 
Alton Hernandez
Ranch Hand
Posts: 443
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Miki Muzsi:
So why do we talk then about N locks on the same object? Does JVM keeps internally a count, representing the nr of lcoks on the same object?

Consider this program:

If you look at the bytcode of the run method, it performs the monitorenter opcode twice.



Why is a boolean logic not good enough?

I think locks are implemented using semaphores. But I am just guessing here.
 
Marlene Miller
Ranch Hand
Posts: 1392
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So why do we talk then about N locks on the same object?

In method A.m3(), Thread-1 performs 3 unlock actions on the A object and Thread-2 performs 2 unlock actions on the A object.

Output:
m1: Thread-1
m2: Thread-1
m3: Thread-1
m2: Thread-2
m3: Thread-2
Why is a boolean logic not good enough?

The first thread performs 3 lock actions, returns from m3, m2 and m1. Then the virtual machine can release the lock.
The second thread performs 2 lock actions, returns from m3 and m2. Then the virtual machine can release the lock.
[ July 08, 2003: Message edited by: Marlene Miller ]
 
I agree. Here's the link: http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic