[concurrency-interest] ThreadLocal vs ProcessorLocal

Jacy Odin Grannis jacyg at alumni.rice.edu
Thu Oct 18 10:16:08 EDT 2012


In our case, we knew that the operations we were measuring weren't
taking hundreds of milliseconds (because the number of operations
completed in a given time frame precluded that being the case).  And
we also knew, with even more certainty, that the operations weren't
taking NEGATIVE hundreds of milliseconds to complete, because we were
unfortunately not clever enough to create systems that would do that.
Given that we expected values to be in the microsecond range, and we
had counts which backed that up, it was pretty easy to discount values
which were clearly out of range.  Although when we first encountered
the issue, we checked things by simply running a set of threads
getting nanoTime values and noting when the value would suddenly have
a large difference from the previous value, and log those values.  We
noted that the values logged varied significantly from one thread to
the other, and that a given thread would at times start reporting
values which matched up with values which had been reported by a
different thread (i.e. b/c it had been migrated to the core that other
thread had been running on).  We were a bit surprised at how often
even hot threads would migrate.  As far as context switches...yes,
those could be a confounder.  In our case, we knew what the system was
doing very well, and had a very limited number of active threads which
did not exceed our core count, and, as I mentioned, given that we'd
get elapsed time values occasionally which were +/- hundreds of millis
despite simple counts which would indicate that was impossible, well,
eliminating context switches as our issue was not too difficult.
However, as a general rule, no, you can't reject outliers out-of-hand,
you have to do some digging.

jacy

On Thu, Oct 18, 2012 at 9:00 AM, oleksandr otenko
<oleksandr.otenko at oracle.com> wrote:
> How do you differentiate wildly different value on the same CPU after a
> context switch and a wildly different value on another CPU after a context
> switch?
>
> Alex
>
>
> On 17/10/2012 22:55, Jacy Odin Grannis wrote:
>
> 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.
>
> Jacy
>
> On Wed, Oct 17, 2012 at 4:30 PM, Dr Heinz M. Kabutz
> <heinz at javaspecialists.eu> wrote:
>
> [newbie question]
>     Is it possible for a thread to ever be moved between processors, if for
> example the is an idle processor and another that is really busy?  If not,
> then load balancing could be problematic.  If yes, then this means that we
> need to take this into consideration and not build static structures based
> on the value of which processor the thread is currently running on.
>
> Again, if no, then what is the guarantee that it won't be available on some
> VMs or some hardware architectures or operating systems?
> [/newbie question]
>
> Regards
>
> Heinz
> --
> Dr Heinz M. Kabutz (PhD CompSci)
> Author of "The Java(tm) Specialists' Newsletter"
> Sun Java Champion
> IEEE Certified Software Development Professional
> http://www.javaspecialists.eu
> Tel: +30 69 75 595 262
> Skype: kabutz
>
>
>
> On 10/17/12 11:05 AM, Romain Colle wrote:
>
> On Wed, Oct 17, 2012 at 9:15 AM, Kirk Pepperdine <kirk at kodewerk.com> wrote:
>
> SOT, right now we are using CPUID for a number of reasons. Very easy to
> get to on Linux as we can do this in pure Java. However other platforms
> require C++/assembler so having <gulp> an unsafe operation in the JVM would
> be a win from my POV.
>
> I strongly second that. It is next to impossible to implement most
> NUMA-aware algorithms without knowing on which NUMA node the current thread
> is running.
> Having this information available as a Java class (in Thread, Unsafe, ...)
> would be a huge win for people like us that need NUMA-aware behavior.
>
> Cheers,
>
> --
> Romain Colle
> R&D Project Manager
> QuartetFS
> 2 rue Jean Lantier, 75001 Paris, France
> http://www.quartetfs.com
>
> ________________________________
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest


More information about the Concurrency-interest mailing list