[concurrency-interest] ThreadLocal vs ProcessorLocal

Jacy Odin Grannis jacyg at alumni.rice.edu
Wed Oct 17 17:55:50 EDT 2012


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
>


More information about the Concurrency-interest mailing list