[concurrency-interest] ScheduledThreadPoolExecutor schdeuling problem ?

Hanson Char hanson.char at gmail.com
Tue Jan 1 14:23:46 EST 2008

Hi David,

In the context of a particular machine, assuming there is an imaginery
real absolute current clock time C, is it always true that
System.currentTimeMillis() is less than or equal to C ?

Or can I not even make such assumption ?

Hanson Char

On Jan 1, 2008 1:34 AM, David Holmes <dcholmes at optusnet.com.au> wrote:
> A few general comments:
> As you noticed you have to be very careful about trying to measure
> timer-based library functions using an "external" clock source. Even with
> nanoTime you only get an approximation of measuring what you want to
> measure. currentTimeMillis() is typically only updated every 10ms hence the
> apparent 10ms "early release".
> The API's used for clocks and timers are inherently broken to varying
> degrees on all operating systems used by Java: linux, Windows and even
> Solaris. See my blog entry for some of the issues on Windows:
> http://blogs.sun.com/dholmes/entry/inside_the_hotspot_vm_clocks
> and you have to be clear on the difference between the timer mechanisms used
> to trigger time-based events, versus the clock mechanisms used to read
> elapsed or current time. Most OSes only support low resolution timers at the
> "user" level.
> nanoTime is a more expensive operation on many newer systems these days. For
> a brief period the TSC on uniprocessor systems offered a very fast high
> resolution time source. But the TSC on MP systems is fundamentally broken
> until new chips provide TSC synchronization across cores and with stable
> frequencies, and so is no longer used for a high resolution time source by
> many OSes. Most OSes provide a "time-of-day" value (used by
> currentTimeMillis) that is basically a global variable and so reading it
> just involves accessing a memory location. Whereas the high resolution
> timers used by nanoTime require, in many cases, going out to a device that
> is more complicated to access (a memory-mapped HPET is not too expensive,
> about the same as the local APIC timer, but the ACPI power management timer
> and/or old PIT timer can involve slow IO instructions.)
> Aside: hotspot recently introduced code in Java 7 to cache the value used by
> currentTimeMillis() to avoid excessive calls to gettimeofday, which were
> proving expensive in some use cases. The downside of that is that the
> resolution falls to about 50ms and so you have to enable it explicitly.
> Be wary of trying to establish accurate absolute times - even if API's
> appear to support them. The way in which OSes manipulate absolute times is
> fundamentally broken in some cases, as they switch between absolute and
> relative at different layers of the OS.
> Cheers,
> David Holmes
> > -----Original Message-----
> > From: concurrency-interest-bounces at cs.oswego.edu
> > [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Doug Lea
> > Sent: Tuesday, 1 January 2008 7:16 AM
> > To: Hanson Char
> > Cc: ferraro at users.sourceforge.net; John Xiao (ex-Amazon);
> > concurrency-interest
> > Subject: Re: [concurrency-interest] ScheduledThreadPoolExecutor
> > schdeuling problem ?
> >
> >
> > Hanson Char wrote:
> > > Oops, not accuracy but precision, as stated in the
> > System.nanoTime javadoc:
> > >
> > >     "This method provides nanosecond precision, but not necessarily
> > > nanosecond accuracy"
> > >
> > > But still, I would imagine it would costs more to compute the
> > > nano-time than milli-time.
> >
> > Generally, the opposite, but there are no guarantees.
> > On most platforms nanoTime is cheaper than currentTimeMillis,
> > on others about the same. But I don't think there
> > are any platforms on which the performance
> > difference is big enough in either direction to
> > cause anyone to choose one versus the other on performance
> > grounds alone.
> >
> > -Doug
> > _______________________________________________
> > 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