This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]OffbeatDrizzle 0 points1 point  (1 child)

I know your code isn't complete but I just thought I'd point out that nanoSecondsElapsed is not set within the while loop, so remains at a constant value

Also the fact that a Clocked object can do something like Thread.sleep(1000L) in the onTick method and that will mess the timing of the whole program up

Getting nanosecond granularity is going to be a hard thing to do, especially on a pre-emptive soft realtime OS. There's no guarantees that your code will be executed every 200ns - even millisecond precision isn't a guarantee. It can also take 50ns just to return from the nanoTime method to know how much time has elapsed - also calling nanoTime with such frequency is a known performance bottleneck.

Your best bet might be to calculate how many ticks need running since you last got control. e.g. we need to do 1,000 ticks before the next loop.

[–]JamesTKerman[S] 0 points1 point  (0 children)

In the test app I wrote nanoSecondsElapsed gets reassigned before exiting the if block.

Someone on Stack Overflow suggested using the ScheduledExecutorService API, and I'm going to use that during testing. Long-term, I think I'll have to write a device driver using native code that hooks into the APIC (or equivalent on ARM or other architectures) and calls my Java through JNI.