Using Object.wait(millisec) to simulate sleep

Question

Here's a snippet of code that I saw in some code I'm maintaining.

Object lock = new Object();

synchronized( lock ) 
{
   try
   {
       lock.wait( 50000 );
       Thread.sleep( 3000 );
   } 
   catch(Exception ex)
   {
   }
}

The developer wants to suspend the current thread for some amount of time and is using Object#wait as the mechanism. Obviously it is bad form to use the wait/notify protocol for this reason; however, is there any major difference between calling wait(millisec) and a Thread.sleep ?

Answer 1

Aside from having to get a monitor before waiting() there's no major difference anymore so long as no one external is going to be .notify()ing.

In ancient Java code you'd see people using wait() instead of Thread.sleep() because Thread.sleep() would freeze the whole application on systems without preemptive multitasking (I'm looking at you OS9). Technically wait() also let's you use nano-resolution waits, but in practice they're seldom that accurate.

Answer 2

Note that there is one key difference in using Object.wait() and Thread.sleep() inside a synchronization block: Thread.sleep() does not release the locked monitor, so no-one else can become the owner of the monitor.

In addition, Object.wait() does not guarantee that the delay indicated will be obeyed strictly. First of all, after the delay passes, the thread may still be waiting for another thread that has become the monitor owner in the meantime; and it may compete with other threads waiting to grab the monitor.

Second, the mythical spurious wake-up, as it is described in the Java 6 API javadoc:

A thread can also wake up without being notified, interrupted, or timing out, a so-called spurious wakeup.

Unlikely as it is, every piece of code using Object.wait() should take it into consideration.