• 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

Difference between wait and sleep

 
Ranch Hand
Posts: 212
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
From the oracle site:

1. sleep(long millis):
Causes the currently executing thread to sleep (temporarily cease execution) for the specified number of milliseconds, subject to the precision and accuracy of system timers and schedulers.

2. wait():
Causes the current thread to wait until another thread invokes the notify() method or the notifyAll() method for this object.

Which of the two releases the lock and which one doesn't?
 
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
The wait() method is integrated with the notify() and notifyAll() methods. It waits for the notification that is sent by the notify methods. It also has to release the locks (including if it is acquire multiple times), so that the notify methods are able to run.

Henry
 
Saloon Keeper
Posts: 27752
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm not sure what "the" lock is. As far as I can envision, if a thread becomes inactive while holding locks, the locks stay held until the thread itself releases them - or is externally killed (which should be an action of last resort).

The wait method waits for an external notification from some other (asynchronous) resource. The sleep method waits for notification from an internal (asynchronous) timer. In either case, the thread goes inactive until the anticipated event occurs, at which time execution resumes. Or, again, until the thread is forcibly terminated.

When you designate a resource as synchronized, the act of synchronization causes a wait to be implicitly performed on the synchronizing lock if that lock already has one or more owners. For that particular instance, the notification occurs when the current resource user leaves synchronization via a return from synchronized method, exception thrown beynod the synchronization scope, or (again) forcible termination of the synchronized thread. In the case of synchronization, the next thread on the synchronization queue ends its wait (receives notification) at that point.
 
Saloon Keeper
Posts: 15484
363
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tim Holloway wrote:if a thread becomes inactive while holding locks, the locks stay held until the thread itself releases them
...
The wait method waits for an external notification from some other (asynchronous) resource. The sleep method waits for notification from an internal (asynchronous) timer. In either case, the thread goes inactive until the anticipated event occurs, at which time execution resumes. Or, again, until the thread is forcibly terminated.


This is wrong. wait() releases a lock. Execution also does not resume when a notification event occurs. The notification merely places the thread from a waiting state in a blocked state; it still has to reacquire the lock.

if that lock already has one or more owners


A lock always has one owner at most. A thread that is in a waiting or blocked state is not the owner of the lock associated with the wait.
 
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

Tim Holloway wrote:I'm not sure what "the" lock is.



In this context, the "lock" being referred to is the synchronization of the object, that is used for wait/notify.

Stephan van Hulst wrote:
A lock always has one owner at most. A thread that is in a waiting or blocked state is not the owner of the lock associated with the wait.



Correct. A synchronization lock may only be acquired by one thread (ie. one owner). However, it is also re-entrant, so, it may be acquired many times, by the same thread.

Henry
 
raja singh kumar
Ranch Hand
Posts: 212
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Can I assume the following 2 points

1. wait() method releases the lock so that other threads can utilize the CPU time?
2. sleep(int) method holds onto the lock and is a waste of CPU time where none of the threads can utilize the CPU time?
 
Stephan van Hulst
Saloon Keeper
Posts: 15484
363
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
1. wait() releases the lock on which you call wait().
2. sleep() is not associated with any locks, so there's nothing to release. You can call sleep() outside of synchronized blocks, it has nothing to do with multi-threading.

Both methods suspend the current thread. That means CPU cycles are not wasted.

You should never call wait() in your application. You should use the classes in java.util.concurrent and java.util.concurrent.locks instead.

You should never call sleep() in your application. It is unreliable, and it's often a sign of a bad application design. If you want to perform tasks periodically, or after some delay, you should use java.util.concurrent.ScheduledExecutorService, or when dealing with Swing, javax.swing.Timer.
 
The harder you work, the luckier you get. This tiny ad brings luck - just not good luck or bad luck.
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic