Thread.sleep() implementation

Question

Today I had an interview on which I asked candidate quite usual and basic question about the difference between Thread.sleep() and Object.wait(). I exp

Answer 1

Do you know any other reasons for not using timed wait in Thread.sleep() implementation?

Because the native thread libraries provide a perfectly good sleep function: http://www.gnu.org/software/libc/manual/html_node/Sleeping.html

To understand why native threads are important, start at http://java.sun.com/docs/hotspot/threads/threads.html

Version 1.1 is based on green threads and won't be covered here. Green threads are simulated threads within the VM and were used prior to going to a native OS threading model in 1.2 and beyond. Green threads may have had an advantage on Linux at one point (since you don't have to spawn a process for each native thread), but VM technology has advanced significantly since version 1.1 and any benefit green threads had in the past is erased by the performance increases over the years.

Answer 2

One could easily say Occam's Razor cuts the other way. The normal/expected implementation of the JVM underlying JDK is assumed to bind java 'threads' onto native threads most of the time, and putting a thread to sleep is a fundamental function of the underlying platform. Why reimplement it in java if thread code is going to be native anyway? The simplest solution is use the function that's already there.

Some other considerations: Uncontested synchronization is negligible in modern JVMs, but this wasn't always so. It used to be a fairly "expensive" operation to acquire that object monitor.

If you implement thread sleeping inside java code, and the way you implement it does not also bind to a native thread wait, the operating system has to keep scheduling that thread in order to run the code that checks if it's time to wake up. As hashed out in the comments, this would obviously not be true for your example on a modern JVM, but it's tough to say 1) what may have been in place and expected at the time the Thread class was first specified that way. and 2) If that assertion works for every platform one may have ever wanted to implement a JVM on.

Answer 3

When a thread is called the sleep method, the thread will be added into a sleep queue. If the compute clock frequency is 100HZ, that means every 10ms the current running process will be interrupted. After reserve the current context of the thread, then it will decrease the value (-10ms) for each thread. When it comes to zero, the thread will move to "waiting for CPU" queue. When time slice comes to this thread, it will be running again. Also because this which not immediately become running, so the time actually sleeps is larger than the value it set.

Answer 4

Thread.sleep() will not be woken up early by spurious wakeups. If using Object.wait(), to do it properly (i.e. ensure you wait enough time) you would need a loop with a query to elapsed time (such as System.currentTimeMillis()) to make sure you wait enough.

Technically you could achieve the same functionality of Thread.sleep() with Object.wait() but you would need to write more code do it correctly.

This is also a relevant and useful discussion.