Question

I have a bizarre problem – I’m hoping someone can explain to me what is happening and a possible workaround. I am implementing a Z80 core in Java, and attempting to slow it down, by using a java.util.Timer object in a separate thread.

The basic setup is that I have one thread running an execute loop, 50 times per second. Within this execute loop, however many cycles are executed, and then wait() is invoked. The external Timer thread will invoke notifyAll() on the Z80 object every 20ms, simulating a PAL Sega Master System clock frequency of 3.54 MHz (ish).

The method I have described above works perfectly on Windows 7 (tried two machines) but I have also tried two Windows XP machines and on both of them, the Timer object seems to be oversleeping by around 50% or so. This means that one second of emulation time is actually taking around 1.5 seconds or so on a Windows XP machine.

I have tried using Thread.sleep() instead of a Timer object, but this has exactly the same effect. I realise granularity of time in most OSes isn’t better than 1ms, but I can put up with 999ms or 1001ms instead of 1000ms. What I can’t put up with is 1562ms – I just don’t understand why my method works OK on newer version of Windows, but not the older one – I’ve investigated interrupt periods and so on, but don’t seem to have developed a workaround.

Could anyone please tell me the cause of this problem and a suggested workaround? Many thanks.

Update: Here is the full code for a smaller app I built to show the same issue:

import java.util.Timer;
import java.util.TimerTask;

public class WorkThread extends Thread
{
   private Timer timerThread;
   private WakeUpTask timerTask;

   public WorkThread()
   {
      timerThread = new Timer();
      timerTask = new WakeUpTask(this);
   }

   public void run()
   {
      timerThread.schedule(timerTask, 0, 20);
      while (true)
      {
         long startTime = System.nanoTime();
         for (int i = 0; i < 50; i++)
         {
            int a = 1 + 1;
            goToSleep();
         }
         long timeTaken = (System.nanoTime() - startTime) / 1000000;
         System.out.println("Time taken this loop: " + timeTaken + " milliseconds");
      }
   }

   synchronized public void goToSleep()
   {
      try
      {
         wait();
      }
      catch (InterruptedException e)
      {
         System.exit(0);
      }
   }

   synchronized public void wakeUp()
   {
      notifyAll();
   }

   private class WakeUpTask extends TimerTask
   {
       private WorkThread w;

       public WakeUpTask(WorkThread t)
       {
          w = t;
       }

       public void run()
       {
          w.wakeUp();
       }
   }
}

All the main class does is create and start one of these worker threads. On Windows 7, this code produces a time of around 999ms – 1000ms, which is totally fine. Running the same jar on Windows XP however produces a time of around 1562ms – 1566ms, and this is on two separate XP machines that I have tested this. They are all running Java 6 update 27.

I find this problem is happening because the Timer is sleeping for 20ms (quite a small value) – if I bung all the execute loops for a single second into wait wait() – notifyAll() cycle, this produces the correct result – I’m sure people who see what I’m trying to do (emulate a Sega Master System at 50fps) will see how this is not a solution though – it won’t give an interactive response time, skipping 49 of every 50. As I say, Win7 copes fine with this. Sorry if my code is too large 🙁

Answer 1

Could anyone please tell me the cause of this problem and a suggested workaround?

The problem you are seeing probably has to do with clock resolution. Some Operating Systems (Windows XP and earlier) are notorious for oversleeping and being slow with wait/notify/sleep (interrupts in general). Meanwhile other Operating Systems (every Linux I’ve seen) are excellent at returning control at quite nearly the moment specified.

The workaround? For short durations, use a live wait (busy loop). For long durations, sleep for less time than you really want and then live wait the remainder.