[concurrency-interest] ScheduledThreadPoolExecutor schdeulingproblem ?

David Holmes dcholmes at optusnet.com.au
Tue Jan 1 17:59:44 EST 2008


Hanson,

I'm not sure exactly what you mean. If C has infinite resolution and follows
wall-clock time (ie DST changes, leap years, leap seconds etc) then an
implementation of currentTimeMillis() that simply reads the current value of
C will always return a value less than or equal to C at the instant C was
read. But a value just returned by currentTimeMillis() could be greater than
C an instant later if C was just adjusted backward for DST.

And in the caching implementation I mentioned for hotspot, C could already
have been adjusted backward while currentTimeMillis() still returns an old
value of C.

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 5:24 AM
> To: dholmes at ieee.org
> Cc: ferraro at users.sourceforge.net; Doug Lea; concurrency-interest; John
> Xiao (ex-Amazon)
> Subject: Re: [concurrency-interest] ScheduledThreadPoolExecutor
> schdeulingproblem ?
>
>
> 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
> > >
> >
> >
> _______________________________________________
> 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