• 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
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

object.wait()

 
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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()
 
Ranch Hand
Posts: 139
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
author
Posts: 23951
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
Nikos kat
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
many thanks for your advice
 
Ranch Hand
Posts: 1780
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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?
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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...
 
Jeff Albertson
Ranch Hand
Posts: 1780
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
When I try to run the codes you suggested:

The code blocks forever. What could be wrong?
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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...
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 1780
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 1780
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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

    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.
     
    Ranch Hand
    Posts: 208
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    ----------------------------------------------------------------------
    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
    Posts: 23951
    142
    jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    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
    Posts: 1078
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator


    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.
     
    Consider Paul's rocket mass heater.
    reply
      Bookmark Topic Watch Topic
    • New Topic