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 expected him to answer something like like this, but he said these methods basically are the same thing, and most likely Thread.sleep is using Object.wait() inside it, but sleep itself doesn’t require external lock. This is not exactly a correct answer, because in JDK 1.6 this method have following signature.

public static native void sleep(long millis) throws InterruptedException;

But my second thought was that it’s not that ridiculous. It’s possible to use timed wait to achieve the same effect. Take a look at the following code snippet:

public class Thread implements Runnable {
       private final Object sleepLock = new Object();

     // other implementation details are skipped

       public static void sleep(long millis) throws InterruptedException {
            synchronized (getCurrentThread().sleepLock){
                getCurrentThread().sleepLock.wait(millis);
            }
        }

In this case sleepLock is an object which is used particularly for the synchronization block inside sleep method. I assume that Sun/Oracle engineers are aware of Occam’s razor, so sleep has native implementation on purpose, so my question is why it uses native calls.

The only idea I came up with was an assumption that someone may find useful invocation like Thread.sleep(0). It make sense for scheduler management according to this article:

This has the special effect of clearing the current thread’s quantum and putting it to the end of the queue for its priority level. In other words, all runnable threads of the same priority (and those of greater priority) will get a chance to run before the yielded thread is next given CPU time.

So a synchronized block will give unnecessary overhead.

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

Answer 1

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.