[concurrency-interest] ThreadLocal vs ProcessorLocal

David Dice david.dice at gmail.com
Wed Oct 17 22:11:27 EDT 2012

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
> Message-ID:
>         <CAESiqEqAteCAsCDLWXM-3-89bJS2nBRrLtOBmHrJkkcX2=
> Sh4g at mail.gmail.com>
> 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 (
> https://wiki.rice.edu/confluence/display/HABANERO/Habanero+Multicore+Software+Research+Project
> ).  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

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20121017/1d2dfe4f/attachment-0001.html>

More information about the Concurrency-interest mailing list