[concurrency-interest] ThreadLocal vs ProcessorLocal

David Dice david.dice at gmail.com
Wed Oct 17 17:53:54 EDT 2012


Most operating systems will migrate threads if there's a gross or
persistent imbalance in ready queue lengths.   Solaris uses both stealing
and dealing for instance.  And, at least in Solaris, there's no single
unitary scheduler, each of the CPUs is making local decisions that
contribute to the collective policy.    At that same time there's usually
back-pressure in the scheduling policies to try to reduce the migration
rate, at least between NUMA nodes.   (See "seance communication" :
http://dx.doi.org/10.1145/377769.377780).    To make it even more exciting
we can throw energy policies into the equation.    But migration is a fact
of life that we have to live with -- it's not uncommon.    It can also
occur when customers repartition resources on a running system.

Regards
Dave



On Wed, Oct 17, 2012 at 5: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 Professionalhttp://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 listConcurrency-interest at cs.oswego.eduhttp://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20121017/f8a437f8/attachment.html>


More information about the Concurrency-interest mailing list