[concurrency-interest] ScheduledThreadPoolExecutor schdeuling problem ?
dcholmes at optusnet.com.au
Tue Jan 1 04:34:13 EST 2008
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:
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
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.
> -----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);
> 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.
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
More information about the Concurrency-interest