Thread.join(millisecond) is not accuracy in java?

Question

As we all know in java, Thread.join(long millis) means "Waits at most millis milliseconds for this thread to die", but i find the millisecond is not very accuracy, please see the following code:

public class MyThreadTest {
public void invokeTest() {
    long executionTimeLimit = 10;
    Runner rn = new Runner();
    rn.start();
    try {
        long time = System.currentTimeMillis();
        rn.join(executionTimeLimit);
        long l1 = (System.currentTimeMillis() - time);
        System.out.println("execution_time_limit="+executionTimeLimit+" the invoke method time is "+l1+" millisecond");
    } catch (Exception e) {
        //e.printStackTrace();
    }
}
public static void main(String args[]) {
    MyThreadTest mtt = new MyThreadTest();
    mtt.invokeTest();
}
private final class Runner extends Thread {
    public void run()
    {
        //to make the program a bit longer
        int size = 3000;
        String[][] bb = new String[size][size];
        for(int i=0;i<size;i++) 
            for(int j=0;j<size;j++) {
                bb[i][j] = "bbbbbbbbbbb";
        }

    }
}
}

the output log is not same when you running more than one times:

"execution_time_limit=10 the invoke method time is 11 millisecond" "execution_time_limit=10 the invoke method time is 32 millisecond" "execution_time_limit=10 the invoke method time is 34 millisecond"

why does that happen?

When measuring durations there's a general problem with timer/clock accuracy. Have a look here: http://stackoverflow.com/questions/351565/system-currenttimemillis-vs-system-nanotime — Thomas, Dec 06 '13 at 14:58
It's not even a Java issue. If you want high precision thread scheduling you'll most likely end up spin locking. — zapl, Dec 06 '13 at 15:02

Peter Lawrey · Accepted Answer · 2013-12-06T18:32:06.583

3

When you wait(n) or sleep(n) and it is not interrupted or notify()ed, it waits for at least the time given. In join(n) both is possible. It wakes early on a notify/end of thread, but can wake at any time after that.

The variation is between when a thread could wake and when it does wake is so wide there are tools which monitor such things. jHiccup being one of the best.

When a thread wakes up is dependant onload, but also the OS. This can lead to threads waking long after they should. A recent question for MacOS concerned delays of up to 10 second delay for a idle system.

This is something Java has no control over, it is down to your OS.

BTW if you look at jitter on the micro-second level you see much more colourful variations/jitter/interrupts of processes.

Micro jitter, busy waiting and binding CPUs

edited Dec 06 '13 at 18:32

answered Dec 06 '13 at 14:58

Peter Lawrey

525,659
79
751
1,130

`at least the time given, but it could wake early` Did you mean _at most_? – Sotirios Delimanolis Dec 06 '13 at 15:04
@SotiriosDelimanolis join() is based on wait()/notify(). If notify is not called, wait will wake some time after the time out. i.e. when the OS gets round to it. – Peter Lawrey Dec 06 '13 at 15:26
1

My comment was just to change the way you say it. You can't say _at least_, but then say it could wake early. If it's the least, there's nothing before it. Might confuse someone (definitely not me :p). – Sotirios Delimanolis Dec 06 '13 at 15:28

score 0 · Answer 2 · answered Dec 06 '13 at 14:56

When we deal with threads, we can never ensure the time accuracy as these operations like wait, join, sleep are also dependant on system resources' availability.

Check Oracle tutorials http://docs.oracle.com/javase/tutorial/essential/concurrency/join.html

score 0 · Answer 3 · answered Dec 06 '13 at 15:13

The doxygen is just confusing you, because it says "Waits at most millis milliseconds for this thread to die".

The join() function just allows the calling thread to "wait for a while" rather than stuck forever. When the join() function returns, the thread you called it on might still be running (i.e. it didn't "joined"). In this case join() would have waited for at least millis milliseconds, then that thread didn't finish and join() gave up. On the other hand, if the thread join() has been called on did actually finish than join() would have waited for less than millis milliseconds.

Bear also in mind that unless you're JVM is running on a Real Time Operating System (and those threads have certains priorities), other processes/threads can be scheduled causing join() return to be delayed even longer (which happened when you've got 34ms rather than 11ms).

Thread.join(millisecond) is not accuracy in java?

3 Answers3

Linked