[concurrency-interest] ThreadLocal vs ProcessorLocal

David M. Lloyd david.lloyd at redhat.com
Wed Aug 10 13:55:30 EDT 2011

On 08/10/2011 11:38 AM, Nathan Reynolds wrote:
> I would like to recommend that we stripe data structures using a
> ProcessorLocal instead of ThreadLocal.  ProcessorLocal (attached) is
> exactly like ThreadLocal except the stored objects keyed off of the
> processor instead of the thread.  In order to implement ProcessorLocal,
> it needs an API that returns the current processor id that the thread is
> running on.  The HotSpot team has filed an RFE and are planning on
> providing such an API.  (Many of you are already aware of this.)

A couple questions/comments - first, using CHM would seem to undermine a 
lot of the potential of ProcessorLocal due to its relatively heavy 
weight and extra locking.  You avoid arrays due to false sharing, yet it 
seems to me that the array could be padded out, or you could use an 
array of holder objects, etc. and save both memory and unnecessary 
processing in the CHM.

Second, is there any provision for the number of CPUs changing at runtime?


More information about the Concurrency-interest mailing list