[concurrency-interest] ThreadLocal vs ProcessorLocal

oleksandr otenko oleksandr.otenko at oracle.com
Thu Oct 18 10:00:15 EDT 2012


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20121018/b217b391/attachment-0001.html>


More information about the Concurrency-interest mailing list