Help coderanch get a
new server
by contributing to the fundraiser
  • 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Devaka Cooray
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • paul wheaton
  • Henry Wong
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Tim Moores
  • Carey Brown
  • Mikalai Zaikin
Bartenders:
  • Lou Hamers
  • Piet Souris
  • Frits Walraven

wait() in synchronized code ??

 
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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!
 
Ranch Hand
Posts: 44
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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().
���������
 
Ranch Hand
Posts: 3244
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 3244
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
reply
    Bookmark Topic Watch Topic
  • New Topic