[concurrency-interest] ThreadLocal vs ProcessorLocal

David Holmes davidcholmes at aapt.net.au
Wed Oct 17 23:18:22 EDT 2012

You can see nanoTime go backwards in a single-thread if the thread changes
cores and the TSC on the second core has a smaller value than that on the

David Holmes

  -----Original Message-----
  From: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Ariel
  Sent: Thursday, 18 October 2012 12:49 PM
  To: David Dice; concurrency-interest at cs.oswego.edu
  Subject: Re: [concurrency-interest] ThreadLocal vs ProcessorLocal


  I would swear I have seen nanotime go backwards within a single thread.
Could be an application bug I suppose, but we were convinced.

  I also saw performance issues with nanotime so I ended up only sampling 1
in 20 transactions.

  On Wed, Oct 17, 2012, at 10:11 PM, David Dice wrote:

      Date: Wed, 17 Oct 2012 16:55:50 -0500
      From: Jacy Odin Grannis <jacyg at alumni.rice.edu>
      To: "Dr Heinz M. Kabutz" <heinz at javaspecialists.eu>
      Cc: concurrency-interest at cs.oswego.edu, David Dice
              <david.dice at gmail.com>
      Subject: Re: [concurrency-interest] ThreadLocal vs ProcessorLocal
              <CAESiqEqAteCAsCDLWXM-3-89bJS2nBRrLtOBmHrJkkcX2=Sh4g at mail.gmai
      Content-Type: text/plain; charset=ISO-8859-1

      Yes, definitely.  I've seen this happen.  One easy way you can see
      this is System.nanoTime will suddenly start returning wildly different
      values.  nanoTime is only consistent on a single processor, it can
      vary widely between processors (at least on Linux).

      I think what's really needed is a set of language level constructs for
      really addressing the problem.  I know there are experimental projects
      looking to do that (
      ).  I am not sure to what extent it would be possible to build support
      for the various constructs in the JVM; and then aside from that, how
      you would add language support is another matter.

    The nanoTime() behavior sounds like a JVM bug.   nanoTime() values
should be non-retrograde and causal in the sense that if one thread calls
nanoTime and stores the observed value T into a variable, and then some 2nd
thread reads that variable and observes the store of T and then calls
nanoTime and sees value U, we should have U >= T.  (Volatiles are assumed,
obviously).     I first ran into this non-monotonic time problem on large
SPARC systems where the HW clock underlying the native gethrtime() API
exhibited drift between CPUs.   The drift was minimal as the kernel syncs
the clocks periodically, so we tracked the the maximum value returned by
nanoTime() and would return the maximum of that tracking value and the value
we got via gethrtime().   This works, but creates its own cache coherence
hot-spot as we're updating that variable frequently, which means that
concurrent and unrelated nanoTime() calls don't scale as well as we might
like.   (There are ways to avoid the coherence hot spot but they usually
entail reduced accuracy).

    It's been years since I've looked at the code, but I think we use
CLOCK_MONOTONIC if it's available on linux.   (David Holmes could best
answer this part of the question regarding linux time sources).  But the
guards against returning a smaller value aren't in place in the linux
platform-specific code as they are on Solaris.


    Concurrency-interest mailing list
    Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20121018/c99fb242/attachment-0001.html>

More information about the Concurrency-interest mailing list