[concurrency-interest] ThreadLocal vs ProcessorLocal

Ariel Weisberg ariel at weisberg.ws
Wed Oct 17 22:48:52 EDT 2012


Hi,

[1]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.

Ariel
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 <[2]jacyg at alumni.rice.edu>
  To: "Dr Heinz M. Kabutz" <[3]heinz at javaspecialists.eu>
  Cc: [4]concurrency-interest at cs.oswego.edu, David Dice
          <[5]david.dice at gmail.com>
  Subject: Re: [concurrency-interest] ThreadLocal vs ProcessorLocal
  Message-ID:

  <CAESiqEqAteCAsCDLWXM-3-89bJS2nBRrLtOBmHrJkkcX2=[6]Sh4g at mail.gmail.c
  om>
  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 (
  [7]https://wiki.rice.edu/confluence/display/HABANERO/Habanero+Multic
  ore+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 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.

Regards
Dave

_______________________________________________

Concurrency-interest mailing list

[8]Concurrency-interest at cs.oswego.edu

[9]http://cs.oswego.edu/mailman/listinfo/concurrency-interest

References

1. https://issues.voltdb.com/browse/ENG-1132
2. mailto:jacyg at alumni.rice.edu
3. mailto:heinz at javaspecialists.eu
4. mailto:concurrency-interest at cs.oswego.edu
5. mailto:david.dice at gmail.com
6. mailto:Sh4g at mail.gmail.com
7. https://wiki.rice.edu/confluence/display/HABANERO/Habanero+Multicore+Software+Research+Project
8. mailto:Concurrency-interest at cs.oswego.edu
9. http://cs.oswego.edu/mailman/listinfo/concurrency-interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20121017/93f68834/attachment.html>


More information about the Concurrency-interest mailing list