views:

2342

answers:

7

What is the difference between a wait() and sleep() in Threads?

Is my understanding that a wait()-ing Thread is still in running mode and uses CPU cycles but a sleep()-ing does not consume any CPU cycles correct?

Why do we have both wait() and sleep(): how does their implementation vary at a lower level?

+26  A: 

A wait can be "woken up" by another process calling notify on the monitor which is being waited on whereas a sleep cannot. Also a wait (and notify) must happen in a block synchronized on the monitor object whereas sleep does not:

Object mon = ...;
synchronized (mon) {
    mon.wait();
}

At this point the currently executing thread waits and releases the monitor. Another thread may do

synchronized (mon) { mon.notify(); }

(On the same mon object) and the first thread (assuming it is the only thread waiting on the monitor) will wake up.

You can also call notifyAll if more than one thread is waiting on the monitor - this will wake all of them up. However, only one of the threads will be able to grab the monitor (remember that the waitis in a synchronized block) and carry on - the others will then be blocked until they can acquire the monitor's lock.

Another point is that you call wait on Object itself (i.e. you wait on an object's monitor) whereas you call sleep on Thread.

Yet another point is that you can get spurious wakeups from wait (i.e. the thread which is waiting resumes for no apparent reason). You should always wait whilst spinning on some condition as follows:

synchronized {
    while (!condition) mon.wait();
}
oxbow_lakes
A sleeping Thread can also be woken up by notify(). ?
Geek
No, it cannot. It can only be interrupted.
Peter Štibraný
No - a sleeping thread cannot be woken by notify
oxbow_lakes
but you can interrupt a sleeping Thread. In that case wait() is redundant infact it wastes CPU cycles too :-(
Geek
When you are interrupting, you must know which thread you want to interrupt. When you're calling notify, you just need object, and you don't care if there is any other thread which 'waits' on this object. wait/notify is used for communication, while sleep is used for, ehm, sleeping.
Peter Štibraný
@Geek - why in the world do you say wait() wastes CPU cycles?
Robert Munteanu
@Robert - I could be wrong :-(
Geek
A: 

In simple words, wait is wait Until some other thread invokes you whereas sleep is "dont execute next statement" for some specified period of time.

Moreover sleep is static method in Thread class and it operates on thread, whereas wait() is in Object class and called on an object.

Another point, when you call wait on some object, the thread involved synchronize the object and then waits. :)

Ratnesh Maurya
Why do you need both ? Why sleep() is not sufficient ?
Geek
Notify is used for communication between threads. To call wait, you need some object, synchronize on it, and then call wait on it. To be notified, you need other thread to synchronize on the *same* object, and call notify.
Peter Štibraný
+1  A: 

Wait and Sleep are very different. Sleep has no way of "waking-up", whereas Wait has a way of "waking-up" during the wait period, by another thread calling notify or notifyAll.

Come to think about it, the names are confusing in that respect; however Sleep is a standard name and Wait is like the WaitForSingleObject or WaitForMultipleObjects in the Win API.

Roee Adler
+3  A: 

Wait and sleep are two different things:

  • In sleep() the thread stops working for the specified duration.
  • In wait() the thread stops working until the object being waited-on is notified.
Itay
but you can interrupt a sleeping Thread. In that case wait() is redundant infact it wastes CPU cycles too :-(
Geek
Wait doesn't waste CPU cycles.
Peter Štibraný
@Peter - I think it does. It waits() for its chunk of CPU cycles and then the OS gives the CPU cycles to other Threads. I think this might be OS dependant, I am not sure.
Geek
It would be very poor implementation of wait() if it wasted CPU cycles. wait/notify is used quite a lot for interthread communication.
Peter Štibraný
Mate, you were right :-)
Geek
You can of course call wait(long) which will only wait for a given amount of time
oxbow_lakes
+2  A: 

check the following link

http://www.jguru.com/faq/view.jsp?EID=47127

rahul
A: 

You are correct - Sleep() causes that thread to "sleep" and the CPU will go off and process other threads (otherwise known as context switching) wheras I believe Wait keeps the CPU processing the current thread.

We have both because although it may seem sensible to let other people use the CPU while you're not using it, actualy there is an overhead to context switching - depending on how long the sleep is for, it can be more expensive in CPU cycles to switch threads than it is to simply have your thread doing nothing for a few ms.

Also note that sleep forces a context switch.

Also - in general it's not possible to control context switching - during the Wait the OS may (and will for longer waits) choose to process other threads.

Kragen
+2  A: 

One key difference not yet mentioned is that while sleeping a Thread does not release the locks it holds, while waiting releases the lock on the object that wait() is called on.

synchronized(LOCK) {
    Thread.sleep(1000); // LOCK is held
}


synchronized(LOCK) {
    LOCK.wait(); // LOCK is not held
}
Robert Munteanu
Waiting only releases the lock for the object you *call* wait() on. It doesn't release any *other* locks.
Jon Skeet
@Jon Skeet: thanks, corrected.
Robert Munteanu
You don't actually need to call sleep from within a lock - locks and wait/notify go hand in hand but locks and sleep are unrelated.
oxbow_lakes
@oxbow_lakes - I'd say that you should not sleep with locks, there are few uses cases for that. Just wanted to point out the differences.
Robert Munteanu
@oxbow_lakes - I think our edits overlapped so I rolled back to a previous version.
Robert Munteanu
@Robert - agreed; hence my upvote
oxbow_lakes