Why Some Thread.sleep() Are Not Interrupted?

[dazhuxiaokai]

First, see this code.
Very simple, there are 1000 threads, named thread1~thread500 and thread1-sleep~thread500-sleep.
Every threadi-sleep sleeps for 10 seconds and threadi interrupts it:

public class InterruptTest {
   
    public static void main(String[] args) throws Exception {
        for (int i = 1; i <= 500; i++) {
            Thread t = new Interrupt();
            t.setName("thread" + i);
            t.start();
        }
    }
   
    private static class Interrupt extends Thread {
        public void run() {
            Thread t = new Sleep();
            t.setName( getName() + "-sleep" );
            t.start();
            t.interrupt();
            System.out.println( System.currentTimeMillis() + " " +
                                t.getName() + " " + t.isInterrupted() );
        }
    }
   
    private static class Sleep extends Thread {
        public void run() {
            try {
                Thread.sleep(10000);
            } catch (Exception e) {
                return;
            }
            System.err.println( System.currentTimeMillis() + " No! " +
                                getName() + " " + isInterrupted() );
        }
    }

}

I supposed the last System.err.println() should never be executed, because the Thread.sleep() must be interrupted and it should go to the return. But the program did output to stderr:

1304393164531 No! thread349-sleep true
1304393164562 No! thread428-sleep false

It doesn't output every time, looks it happens occasionally.
As you can see, I let it output a line after every interrupt() statement. And I found 2 lines of output in stdout, I put them together with the stderr output:

1304393163531 thread349-sleep true
1304393163562 thread428-sleep true
1304393173531 No! thread349-sleep true
1304393173562 No! thread428-sleep false

Notice the time: 1304393163531 and 1304393173531, I'm sure the 2 interrupt() statements have been executed, exactly 10 seconds before the stderr output. So why weren't they interrupted?

P.S. I have tried 3 computers, they are all Windows XP. And this situation happened on 2 of them, which are Core 2 Duo 2.4GHz. And it didn't happend on another PC, which is Celeron 1.5GHz! Their JDK are the same, version 1.6.

[kjkrum]

It's entirely possible that an Interrupt thread could be suspended after calling t.start() and not call t.interrupt() until after t has finished executing. Or a Sleep thread could be interrupted after sleeping, but before printing its message.

[ra4king]

Remember you have 1000 threads. That is a crapload of code executing at the same time. You can't really predict what may or may not happen under such heavy load! However, that is quite weird how the same object prints "true" for "isInterrupted()" and 10 seconds later, it prints false O.o?

[dazhuxiaokai]

It's entirely possible that an Interrupt thread could be suspended after calling t.start() and not call t.interrupt() until after t has finished executing. Or a Sleep thread could be interrupted after sleeping, but before printing its message.

But notice I output the time. You can see, the interrupted() finished 10 seconds before. So It didn't look like what you said.

[dazhuxiaokai]

Remember you have 1000 threads. That is a crapload of code executing at the same time.

But it was strange that it only happened on a high-performance CPU but never happened on a low-performance CPU.

[dazhuxiaokai]

Would any of you run this code on your own machine and see if the problem also happens? (You need to run many times to see the stderr output)

[JosAH]

         
t.start();
t.interrupt();

If Thread t hasn't started yet the interrupt() method doesn't do anything. Put another sleep() call between those methods and see what happens.

kind regards,

Jos

[kjkrum]

I don't know enough about the internals of the Thead class to say for sure what might be happening. It might even be JVM-specific. But it's no surprise that you're seeing it on your multi-core CPU and not on the others.

The JVM specification allows threads to cache their own copies of variables, and the caches aren't synchronized (in the general sense) unless you synchronize all access to shared variables (in the Java keyword 'synchronized' sense). So it may be a synchronization issue, not just a timeslicing issue.