This week's giveaway is in the EJB and other Java EE Technologies forum.
We're giving away four copies of EJB 3 in Action and have Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan on-line!
See this thread for details.
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes wait() releases all locks? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "wait() releases all locks?" Watch "wait() releases all locks?" New topic
Author

wait() releases all locks?

Miki Muzsi
Ranch Hand

Joined: Jun 23, 2003
Posts: 120
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<br /> <br />SCJP 1.4, SCBCD 1.3
Miki Muzsi
Ranch Hand

Joined: Jun 23, 2003
Posts: 120
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

Joined: Mar 05, 2003
Posts: 1391
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

Joined: Mar 05, 2003
Posts: 1391
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

Joined: Mar 05, 2003
Posts: 1391
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

Joined: Jun 23, 2003
Posts: 120
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

Joined: May 30, 2003
Posts: 443

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

Joined: Jun 23, 2003
Posts: 120
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

Joined: May 30, 2003
Posts: 443
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

Joined: Mar 05, 2003
Posts: 1391
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
 
subject: wait() releases all locks?
 
Similar Threads
thread overview.
Basic thread doubt
about threads, using locks of the objects in synchronized blocks
wait() and lock
Locking trouble...