CODEWITHSUNDEEP
javamultithreading
Manish Patel
Manish Patel

Reputation: 4491

How to achieve a guaranteed sleep time on a thread

I have a requirement for a class method to be called every 50 milliseconds. I don't use Thread.sleep because it's very important that it happens as precisely as possible to the milli, whereas sleep only guarantees a minimum time. The basic set up is this:

public class ClassA{
    public void setup(){
        ScheduledExecutorService se = Executors.newScheduledThreadPool(20);
        se.scheduleAtFixedRate(this::onCall, 2000, 50, TimeUnit.MILLISECONDS);
    }

    protected void onCall(Event event) {
        // do something
    }
}

Now this by and large works fine. I have put System.out.println(System.nanoTime) in onCall to check its being called as precisely as I hope it is. I have found that there is a drift of 1-5 milliseconds over the course of 100s of calls, which corrects itself now and again.

A 5 ms drift unfortunately is pretty hefty for me. 1 milli drift is ok but at 5ms it messes up the calculation I'm doing in onCall because of states of other objects. It would be almost OK if I could get the scheduler to auto-correct such that if it's 5ms late on one call, the next one would happen in 45ms instead of 50.

My question is: Is there a more precise way to achieve this in Java? The only solution I can think of at the moment is to call a check method every 1ms and check the time to see if its at the 50ms mark. But then I'd need to maintain some logic if, on the off-chance, the precise 50ms interval is missed (49,51).

Thanks

Upvotes: 4

Views: 1607

Answers (5)

Marco13
Marco13

Reputation: 54649

According to the comment, the primary goal is not to concurrently execute multiple tasks at this precise interval. Instead, the goal is to execute a single task at this interval as precisely as possible.

Unfortunately, neither the ScheduledExecutorService nor any manual constructs involving Thread#sleep or LockSupport#parkNanos are very precise in that sense. And as pointed out in the other answers: There may always be influencing factors that are beyond your control - namely, details of the JVM implementation, garbage collection, JIT runs etc.

Nevertheless, a comparatively simple approach to achieve a high precision here is busy waiting. (This was already mentioned in an answer that is now deleted). But of course, this has several caveats. Most importantly, it will burn processing resources of one CPU. (And on a single-CPU-system, this may be particularly bad).

But in order to show that it may be far more precise than other waiting approaches, here is a simple comparison of the ScheduledExecutorService approach and the busy waiting:

import java.util.concurrent.Executors;
import java.util.concurrent.ScheduledExecutorService;
import java.util.concurrent.TimeUnit;

public class PreciseSchedulingTest
{
    public static void main(String[] args)
    {
        long periodMs = 50;
        PreciseSchedulingA a = new PreciseSchedulingA();
        a.setup(periodMs);

        PreciseSchedulingB b = new PreciseSchedulingB();
        b.setup(periodMs);
    }
}

class CallTracker implements Runnable
{
    String name;
    long expectedPeriodMs;
    long baseTimeNs;
    long callTimesNs[];
    int numCalls;
    int currentCall;

    CallTracker(String name, long expectedPeriodMs)
    {
        this.name = name;
        this.expectedPeriodMs = expectedPeriodMs;
        this.baseTimeNs = System.nanoTime();
        this.numCalls = 50;
        this.callTimesNs = new long[numCalls];
    }

    @Override
    public void run()
    {
        callTimesNs[currentCall] = System.nanoTime();
        currentCall++;
        if (currentCall == numCalls)
        {
            currentCall = 0;
            double maxErrorMs = 0;
            for (int i = 1; i < numCalls; i++)
            {
                long ns = callTimesNs[i] - callTimesNs[i - 1];
                double ms = ns * 1e-6;
                double errorMs = ms - expectedPeriodMs;
                if (Math.abs(errorMs) > Math.abs(maxErrorMs))
                {
                    maxErrorMs = errorMs;
                }
                //System.out.println(errorMs);
            }
            System.out.println(name + ", maxErrorMs : " + maxErrorMs);
        }
    }

}

class PreciseSchedulingA
{
    public void setup(long periodMs)
    {
        CallTracker callTracker = new CallTracker("A", periodMs);
        ScheduledExecutorService se = Executors.newScheduledThreadPool(20);
        se.scheduleAtFixedRate(callTracker, periodMs, 
            periodMs, TimeUnit.MILLISECONDS);
    }
}

class PreciseSchedulingB
{
    public void setup(long periodMs)
    {
        CallTracker callTracker = new CallTracker("B", periodMs);

        Thread thread = new Thread(new Runnable()
        {
            @Override
            public void run()
            {
                while (true)
                {
                    long periodNs = periodMs * 1000 * 1000;
                    long endNs = System.nanoTime() + periodNs;
                    while (System.nanoTime() < endNs) 
                    {
                        // Busy waiting...
                    }
                    callTracker.run();
                }
            }
        });
        thread.setDaemon(true);
        thread.start();
    }
}

Again, this should be taken with a grain of salt, but the results on My Machine® are as follows:

A, maxErrorMs : 1.7585339999999974
B, maxErrorMs : 0.06753599999999693
A, maxErrorMs : 1.7669149999999973
B, maxErrorMs : 0.007193999999998368
A, maxErrorMs : 1.7775299999999987
B, maxErrorMs : 0.012780999999996823

showing that the error for the waiting times is in the range of few microseconds.

In order to apply such an approach in practice, a more sophisticated infrastructure would be necessary. E.g. the bookkeeping that is necessary to compensate for waiting times that have been too high. (I think they can't be too low). Also, all this still does not guarantee a precisely timed execution. But it may be an option to consider, at least.

Upvotes: 2

Stephen C
Stephen C

Reputation: 718906

Can I achieve a guaranteed sleep time on a thread?

Sorry, but No.

There is no way to get reliable, precise delay timing in a Java SE JVM. You need to use a Real time Java implementation running on a real time operating system.

Here are a couple of reasons why Java SE on a normal OS cannot do this.

  1. At certain points, the GC in a Java SE JVM needs to "stop the world". While this is happening, no user thread can run. If your timer goes off in a "stop the world" pause, it can't be scheduled until the pause is over.

  2. Scheduling of threads in a JVM is actually done by the host operating system. If the system is busy, the host OS may decide not to schedule the JVM's threads when your application needs this to happen.

The java.util.Timer.scheduleAtFixedRate approach is probably as good as you will get on Java SE. It should address long-term drift, but you can't get rid of the "jitter". And that jitter could easily be hundreds of milliseconds ... or even seconds.

Spinlocks won't help if the system is busy and the OS is preempting or not scheduling your threads. (And spinlocking in user code is wasteful ...)

Upvotes: 8

Eugene Marin
Eugene Marin

Reputation: 1796

Yes (assuming you only want to prevent long term drifts and don't worry about each delay individually). java.util.Timer.scheduleAtFixedRate:

...In fixed-rate execution, each execution is scheduled relative to the scheduled execution time of the initial execution. If an execution is delayed for any reason (such as garbage collection or other background activity), two or more executions will occur in rapid succession to "catch up." In the long run, the frequency of execution will be exactly the reciprocal of the specified period (assuming the system clock underlying Object.wait(long) is accurate). ...

Basically, do something like this:

new Timer().scheduleAtFixedRate(new TimerTask() {

        @Override
        public void run() {
            this.onCall();
        }
    }, 2000, 50);

Upvotes: 0

mattm
mattm

Reputation: 5949

If you really have hard time constraints, you want to use a real-time operating system. General computing does not have hard time constraints; if your OS goes to virtual memory in one of your intervals, then you can miss your sleep interval. The real-time OS will make the tradeoff that you may get less done, but that work will can be better scheduled.

If you need to do this on a normal OS, you can spinlock instead of sleeping. This is really inefficient, but if you really have hard time constraints, it's the best way to approximate that.

Upvotes: 1

Michał Zaborowski
Michał Zaborowski

Reputation: 4387

That will be hard - think about GC... What I would do is to grab time with nanoTime, and use it in calculations. Or in other words I would get exact time and use it in calculations.

Upvotes: 0

Related Questions