aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes wait() in synchronized code ?? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "wait() in synchronized code ??" Watch "wait() in synchronized code ??" New topic
Author

wait() in synchronized code ??

Alokesh Phukan
Greenhorn

Joined: May 24, 2001
Posts: 21
Does wait(), notify(), notifyAll() have to be called from synchronized code?
Most mock exams seem to think so.
I did look at the JLS.[JLS $17.14] From what I understood the requirement is that the thread which calls wait() should own the object lock.
Does this necessarily mean the same?
Any examples (if not) would help me a lot!
Trevor Green
Ranch Hand

Joined: May 30, 2001
Posts: 44
A thread must own the lock to call wait() and must give up the lock when it's 'waiting'. To own the lock it must be within a synchronized code block either within a method, or synchronized around an object - this is the lock.
Denis Anoykin
Greenhorn

Joined: Jun 11, 2001
Posts: 8
Usage example:
public class Test extends Thread {
public static class LockThread extends Thread {
Object lock;
intid;
public LockThread (int id, Object lock) {
this.lock = lock;
this.id = id;
}
public void run() {
System.out.println (id+" I will wait notification!");
synchronized (lock) {
try {
lock.wait();
} catch (Exception e) {
e.printStackTrace();
}
}
System.out.println (id+" I receive notification!");
}
}
public static void main(String strs[]) throws Exception {
Object lock1 = new Object();
Object lock2 = new Object();
LockThread t1 = new LockThread(1, lock1);
LockThread t2 = new LockThread(2, lock2);
LockThread t3 = new LockThread(3, lock2);
t1.start();
t2.start();
t3.start();
Thread.currentThread().sleep(200);
synchronized (lock2) {
lock2.notifyAll();
}
synchronized (lock1) {
lock1.notify();
}
}
}
Alokesh Phukan
Greenhorn

Joined: May 24, 2001
Posts: 21

Thanks Trevor, Denis for replying. I sort of had came to the same reasoning as you. But here is a question from Raimondas's mock that seems to suggest that wait() need not be from synchronized code . I tried compiling it and it worked fine.
Q 34.
class�Test�{
����������public�static�void�main(String[]�args)�{
��������������Test�t�=�new�Test();
��������������t.sMethod();
����������}
����������public�synchronized�void�sMethod()�{
��������������method();
����������}
����������private�void�method()�{
��������������try�{
������������������wait(10);
��������������}�catch(InterruptedException�e)�{�}
����������}
������}
1. Code compiles but IllegalMonitorStateException is thrown at runtime.
��2. Code does not compile, wait() must be called from synchronized block or method.
��3. Code does not compile, class Test has to extend Thread or implement Runnable in order to call wait().
��4. Code compiles and runs without exceptions.
Answers : �4

Explanation given : wait()�has�to�be�called�by�thread�which�owns�object's�monitor
(lock).�There�is�no�such�requirement�that�wait()�has�to�be�called�from�within�synchronized�code.�When�main�thread�enters sMethod()�it�owns�monitor�of�this�object.�It�can�then�enter method()�and�call�wait()�because�monitor�is�released�when�thread leaves�sMethod(),�not�when�it�jumps�into�method().
���������
Dave Vick
Ranch Hand

Joined: May 10, 2001
Posts: 3244
Sau
Actually the thread is still in the synchronized code. It hasn't returned from sMethod yet, so it is still inside the method. It may be executing in a different method at the moment but sMethod is still part of the call stack. The line from the example is
...monitor is released when thread leaves sMethod(), ...
and thread doesn't leave sMethod until it travels back up the call stack and is back in main.
Another way to look at it is this.
-- wait() can only be called by a thread that has the lock on a monitor.
-- the only way a thread can get the lock is to be in the synchronized code of the object.
-- if the thread in your example can call wait(), it must be in the synchronized code.

hope that helps
Dave


Dave
Annie Naqvi
Ranch Hand

Joined: May 04, 2001
Posts: 39
Hi Sau,
Infact for a thread to be able to execute wait() it must get the object's lock first and as the lock associated with the object can only be used to execute Synchronozed Instance Method so in your case (the code you wrote) the thread is calling sMethod which is synchronized which is inturn calling unsynchronized method which switch thread at wait state.As the the calling method(sMethod) is sync.so here you don't have to worry for the lock as it is already acquired by the thread.
Regards,
Annie.
Alokesh Phukan
Greenhorn

Joined: May 24, 2001
Posts: 21
Thanks Dave, Annie you really cleared things up for me !
However if an option in a question states that wait() can only be called from synchronized code would that be valid ? Or as you explained it should be specified that the thread that calls wait() would have to be the owner of the object lock ?.
Just want to be sure that there aren't any general ambigous statements in the real exam !
Dave Vick
Ranch Hand

Joined: May 10, 2001
Posts: 3244
Sau
From what I've read the exam has been combed pretty well and there should not be any ambiguos questions on it. I haven't taken it yet so I can't say for sure though.

Dave
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: wait() in synchronized code ??