[concurrency-interest] ScheduledThreadPoolExecutor schdeulingproblem ?

David Holmes dcholmes at optusnet.com.au
Wed Jan 2 07:07:25 EST 2008


Hanson,

I'm unclear on what exactly you are trying to achieve. A high resolution
clock that started out tied to the system clock is of somewhat limited use
in my view - even though the Real-time Specification for Java defines such
as clock. :) What do you achieve by knowing that this clock was at least
once consistent with wall-clock time? In my view you either need absolute
times or relative and if absolute then you need to track wall-clock time.

With current hardware plus OS exposed services you can have either an
absolute time source, or a high resolution one, but not both it seems.

As for the drift between nanoTime and currentTimeMillis ... I don't know the
math for expressing this. I did come across (was sent a link to) a really
good presentation on this but I've lost it and can't remember enough detail
to have google locate it. But google will locate an awful lot on clock
errors and drift :)

Cheers,
David Holmes

> -----Original Message-----
> From: concurrency-interest-bounces at cs.oswego.edu
> [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Hanson
> Char
> Sent: Wednesday, 2 January 2008 8:06 PM
> To: concurrency-interest
> Subject: Re: [concurrency-interest] ScheduledThreadPoolExecutor
> schdeulingproblem ?
>
>
> For scheduling purposes, I wonder if it would make sense to
> instantiate a clock (see below) that can provide consistent
> currentTimeMilli based on nano time, and pass the clock instance
> around.  Places that need to invoke System.currentTimeMilli (for
> scheduling purposes) would then instead invoke the clock's
> currentTimeMilli to obtain a consistent view of time.  This clock's
> currentTimeMilli would be immune to the out-of-date refresh problem of
> System.currentTimeMilli.  However, since the System.nanoTime could be
> implemented on a different hardware device than
> System.currentTimeMilli, such clock would probably gradually diverge
> from the System.currentTimeMilli with no upper bound :-(
>
> Hanson Char
>
> import static java.util.concurrent.TimeUnit.NANOSECONDS;
> import net.jcip.annotations.Immutable;
>
> @Immutable
> public class Clock {
> 	private final long startNano = System.nanoTime();
> 	private final long startMilli = System.currentTimeMillis();
>
> 	public long currentTimeMilli() {
> 		return startMilli +
> NANOSECONDS.toMillis(System.nanoTime() - startNano);
> 	}
> }
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>



More information about the Concurrency-interest mailing list