File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Threads and Synchronization and the fly likes object.wait() Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "object.wait()" Watch "object.wait()" New topic
Author

object.wait()

Nikos kat
Greenhorn

Joined: Jan 20, 2006
Posts: 20
How do you use the object.wait() method. if you put a number in parenthesis is it the wait in milliseconds?

Is this as good as using Thread.wait()
faisal usmani
Ranch Hand

Joined: Jan 14, 2006
Posts: 139
Ok , first of all time is in milliseconds rather in seconds

Now as we know wait() is a method in Object class if you want call wait on Object you have to implement it something like this .


Object ob = new Object();
ob.wait();

Hope i answered you
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18896
    
  40

Originally posted by Nikos kat:
How do you use the object.wait() method. if you put a number in parenthesis is it the wait in milliseconds?

Is this as good as using Thread.wait()


wait() is a method used by threads as a form of communication -- notifications to be exact. Threads calling wait() will be put into a block state until other threads call the notify() method. As such, there is also a requirement of holding synchronization locks, which is freed, and then required, etc.

Anyway, if all you want to do is to put the thread to sleep for X number of milliseconds, you might want to look into the Thread.sleep() method.

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Nikos kat
Greenhorn

Joined: Jan 20, 2006
Posts: 20
many thanks for your advice
Jeff Albertson
Ranch Hand

Joined: Sep 16, 2005
Posts: 1780
Originally posted by faisal usmani:

Now as we know wait() is a method in Object class if you want call wait on Object you have to implement it something like this .

Object ob = new Object();
ob.wait();


When I try to run the codes you suggested:

I am getting the following runtime exception.

I did as you suggested. What could be wrong?


There is no emoticon for what I am feeling!
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
You need to have the object's monitor to be able to call wait:



The same is true for calling notify() and notifyAll().

Moving to Threads and Synchronization...


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Jeff Albertson
Ranch Hand

Joined: Sep 16, 2005
Posts: 1780
When I try to run the codes you suggested:

The code blocks forever. What could be wrong?
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Jeff Albertson:
When I try to run the codes you suggested:

The code blocks forever. What could be wrong?


Nothing. The code *is supposed* to block until another thread calls notify() or notifyAll() *on the same object*.

If you just want to have the thread block for some time, go with Henry's suggestion and use Thread.sleep() instead...
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
Of course, since the object has just been freshly created and no other thread could possibly have a reference to it, that will never happen. I think the larger issue is that there's no context here - what are we trying to do? And I'm not entirely sure if Jeff is asking these questions for his own benefit, or to try to get Faisal to think more about his answer.

Nikos, you should probably find a text that describes using wait() and notify()/notifyAll() together. Until you see them interacting, it's hard to understand what the point of these methods is. The Java tutorial is one place to learn about this.
[ February 06, 2006: Message edited by: Jim Yingst ]

"I'm not back." - Bill Harding, Twister
lakshmi v.samy
Ranch Hand

Joined: Feb 02, 2006
Posts: 30
Hi,
I have read the previous discussion
I tried with notify() and notifyAll()
notify() method is notifying the thread who is waiting at first posisition.

if I use notifyAll() method,it should notify to thread who is having highest priority in the queue.
but it is not happening like that,first thread is getting notification.

please help me,
whether what I understood is wrong about notify,or I might have given any mistakes in code.
Thanks in advance.
Jeff Albertson
Ranch Hand

Joined: Sep 16, 2005
Posts: 1780
Originally posted by Jim Yingst:
And I'm not entirely sure if Jeff is asking these questions for his own benefit, or to try to get Faisal to think more about his answer.


I apologize. I was being a little passive-aggressive. Faisal's reply to the original poster, while correct syntax, isn't the right way to use wait, and Ilja's correction, while getting rid of the monitor exception, isn't workable either. I was just pointing out the these snippets were insufficient.
Jeff Albertson
Ranch Hand

Joined: Sep 16, 2005
Posts: 1780
Originally posted by lakshmi v.samy:
Hi,
I have read the previous discussion
I tried with notify() and notifyAll()
notify() method is notifying the thread who is waiting at first posisition.

if I use notifyAll() method,it should notify to thread who is having highest priority in the queue.
but it is not happening like that,first thread is getting notification.


You have some misconceptions. Here is the relevant part of the JSL (17.8.2):

Notification actions occur upon invocation of methods notify and notifyAll. Let thread t be the thread executing either of these methods on object m, and let n be the number of lock actions by t on m that have not been matched by unlock actions. One of the following actions occurs.
  • If n is zero an IllegalMonitorStateException is thrown. This is the case where thread t does not already possess the lock for target m.
  • If n is greater than zero and this is a notify action, then, if m's wait set is not empty, a thread u that is a member of m's current wait set is selected and removed from the wait set. (There is no guarantee about which thread in the wait set is selected.) This removal from the wait set enables u's resumption in a wait action. Notice however, that u's lock actions upon resumption cannot succeed until some time after t fully unlocks the monitor for m.
  • If n is greater than zero and this is a notifyAll action, then all threads are removed from m's wait set, and thus resume. Notice however, that only one of them at a time will lock the monitor required during the resumption of wait.


  • Note that the wait set is a set -- it is not ordered so there is no "first position". Likewise, there is no mention of thread priority here. I think a naive use of thread priority with notify() could make thread starvation too likely.
    Ken Blair
    Ranch Hand

    Joined: Jul 15, 2003
    Posts: 1078
    Originally posted by lakshmi v.samy:
    notify() method is notifying the thread who is waiting at first posisition


    No it's not. It removes a thread from the wait set. There is no order and priority is not considered. As Jeff said there is no such thing as a first position.

    Originally posted by lakshmi v.samy:
    if I use notifyAll() method,it should notify to thread who is having highest priority in the queue.


    No it shouldn't. All threads are removed from the wait set. This means they will all resume and all immediately attempt to acquire the lock. The first thread to acquire this lock will be the first thread that's able to continue execution. I am unsure if thread priority plays a definitive role in this.

    Originally posted by lakshmi v.samy:
    but it is not happening like that,first thread is getting notification.


    There is no first thread and it's not happening "like that" because that's not at all what the JLS specifies. Your understanding of wait(), notify() and notifyAll() are fatally flawed, it's not a syntactical error.
    vu lee
    Ranch Hand

    Joined: Apr 19, 2005
    Posts: 189
    ----------------------------------------------------------------------
    Notification actions occur upon invocation of methods notify and notifyAll. Let thread t be the thread executing either of these methods on object m, and let n be the number of lock actions by t on m that have not been matched by unlock actions
    --------------------------------------------------------------------

    Could some one throw more light on the bold phrase?
    Henry Wong
    author
    Sheriff

    Joined: Sep 28, 2004
    Posts: 18896
        
      40

    Originally posted by vu lee:

    Notification actions occur upon invocation of methods notify and notifyAll. Let thread t be the thread executing either of these methods on object m, and let n be the number of lock actions by t on m that have not been matched by unlock actions

    Could some one throw more light on the bold phrase?


    Well, this is a snippet, so I can only guess at what it is trying to describe...

    Basically, you are allowed to reacquire a lock that you already own. This is important because it allows synchronized methods to call synchronized methods of the same object. If this wasn't allowed, you would actually deadlock -- the thread that owns the lock is currently waiting for the lock to be free... I am guessing n is the number of times the lock has been acquired.

    Henry
    [ February 10, 2006: Message edited by: Henry Wong ]
    Ken Blair
    Ranch Hand

    Joined: Jul 15, 2003
    Posts: 1078

    17.8.2 Notification
    Notification actions occur upon invocation of methods notify and notifyAll. Let thread t be the thread executing either of these methods on object m, and let n be the number of lock actions by t on m that have not been matched by unlock actions. One of the following actions occurs.

    * If n is zero an IllegalMonitorStateException is thrown. This is the case where thread t does not already possess the lock for target m.
    * If n is greater than zero and this is a notify action, then, if m's wait set is not empty, a thread u that is a member of m's current wait set is selected and removed from the wait set. (There is no guarantee about which thread in the wait set is selected.) This removal from the wait set enables u's resumption in a wait action. Notice however, that u's lock actions upon resumption cannot succeed until some time after t fully unlocks the monitor for m.
    * If n is greater than zero and this is a notifyAll action, then all threads are removed from m's wait set, and thus resume. Notice however, that only one of them at a time will lock the monitor required during the resumption of wait.


    That's the full text from the JLS. When lock and unlock actions occur are specified on that same page in 17.1.


    The synchronized statement (�14.19) computes a reference to an object; it then attempts to perform a lock action on that object's monitor and does not proceed further until the lock action has successfully completed. After the lock action has been performed, the body of the synchronized statement is executed. If execution of the body is ever completed, either normally or abruptly, an unlock action is automatically performed on that same monitor.

    A synchronized method (�8.4.3.6) automatically performs a lock action when it is invoked; its body is not executed until the lock action has successfully completed. If the method is an instance method, it locks the monitor associated with the instance for which it was invoked (that is, the object that will be known as this during execution of the body of the method). If the method is static, it locks the monitor associated with the Class object that represents the class in which the method is defined. If execution of the method's body is ever completed, either normally or abruptly, an unlock action is automatically performed on that same monitor.


    So a lock action happens when entering a synchronized statement or method, also known as a critical section or synchronized block. An unlock action happens when it exits. Logically if a thread has more lock actions then unlock actions for a given monitor then it must hold the lock.

    Does a lock action happen when a thread enters a synchronized method or statement when it already holds the lock? I don't know. The wording of the JLS would seem to indicate so and judging by Henry's reaction I would certainly think it does. This isn't really relevent though, the text would hold true either way and notifications will still work the same either way.

    When calling notify and notifyAll:

    1. If the thread does not have the monitor it will throw an IllegalMonitorStateException.
    2. If the thread has the monitor and it is a notify action, a single thread will be removed from the wait set. In other words, a single thread that had previously called wait on that object will now be notified. Not the first, not the last, not the highest priority, not the lowest, just "a thread". There are no guarantees.
    3. If thehread has the monitor and it is a notifyAll action, all threads will be removed from the wait set. In other words, every thread that had previously called wait on that object will now be notified. All of those threads will have been in a synchronized block when calling wait and therefore all of those threads will need the lock before being able to continue. The thread calling notifyAll holds that lock, once it releases it those other threads will have to compete for it normally and the first to acquire it will logically be the first to continue it's execution.


    I am guessing n is the number of times the lock has been acquired.


    Well, sorta, it's the number of times the lock has been acquired without a matching unlock. I'm pretty sure that's what you meant though.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: object.wait()