[concurrency-interest] Soliciting input about removeAllThreadLocals

Luke Blanshard blanshlu@netscape.net
Sun, 08 Dec 2002 15:14:17 -0600

Hi Josh,

Joshua Bloch wrote:

>> All of this is by way of explaining why I avoid ThreadLocal like the 
>> plague.    Thread-local variables are just global variables in disguise.
>   This is utter nonsense.  Jim Waldo believes (or perhaps believed) it 
> with all his heart and soul, but it's still utter nonsense.  
> ThreadLocal variables are among the least "gloabal-like" of all 
> variables. Thread-locality is orthongonal to other aspects of 
> visibility: you can have a ThreadLocal local variable, a ThreadLocal 
> class variable, a ThreadLocal instance variable, and so forth.  In 
> *every* case, the ThreadLocal version is more "local" (i.e., provides 
> less information sharing) than the "normal" version. 

  Ouch!  I plead ignorance.  Thank you -- and Dawid Kurzyniec -- for 
opening my eyes to the possibility of using ThreadLocal for variables 
with non-global extents.  There are definitely times when this will be 

  However, I was talking about the "class variable," or static, use of 
ThreadLocal -- actually, in my example we didn't use ThreadLocal at all, 
we subclassed Thread and added instance variables to it, but it amounts 
to the same thing.  As with process globals, there are times when this 
is entirely appropriate.  The use in logging, associating numbers to 
threads, is an example: the thread itself is what you want to keep track of.

  But I find your assertion that thread-locals provide less information 
sharing than normal variables a bit baffling.  I think of information 
sharing as being orthogonal to execution path.  There is certainly no 
less code that can share the information.  And it is still the case that 
sharing information through globals -- even thread-local ones -- is 
generally a bad idea, and a red flag.  Much better to explicitly pass 
information in arguments, in 9 cases out of 10.  That's all I meant by 
saying that (static) thread-locals are globals in disguise.

>>  In fact, thread-local variables are worse than global variables in 
>> at least one respect, for exactly the issue you raise here: the same 
>> thread might well be used for more than one purpose. 
>   This is a blame-the-victim mentality.  Blindly reusing a Thread for 
> more than one purpose (e.g., through thread pooling) is dangerous.  
> It's generally done for the purpose optimization. 

  I'd be thrilled if it wasn't necessary.  This is not a case of blind 
optimization, but rather a hard-won piece of knowledge -- creating a new 
Thread for every operation (servlet invocation, e.g.) is prohibitively 

  But if I'm not mistaken, you guys are about to bless the concept of 
thread pools by adding it to the core libraries?  Are we seeing signs of 
dissension among the ranks of the experts here?

  Here's a thought, completely unoriginal to me.  Why not have the JVM 
in charge of thread pooling, multiplexing Java threads across native 
threads as it sees fit?  Then the need for in-Java thread pools goes 
away, and creating a new Thread object for each iteration is cheap.

  And this discussion becomes moot.

>>  So, I'm equanimous on the subject of whether ThreadLocals should be 
>> cleared on each use of a thread.  I won't use them regardless. 
  Well ok, I will use them sometimes -- and more often now that I get 
their use beyond statics.

>  Too bad.  They're a useful tool  You can use them to keep track of 
> thread scopes.  You can use them to safe, fast lazy initialization of 
> per-instance state.  You can use them to assign unique IDs to threads. 
> And yes, you can also use them to hold "thread singleton objects." 
> This technique is often preferable to an instance pool (e.g. a 
> connection pool), as the pool can become an unnecessary concurrency 
> bottleneck. 

  Color me unconvinced on this one -- at least the "often preferable" 
part.  I'd say: first make sure you're never going to want more than one 
such instance available to the same thread; and that you aren't going to 
need a pool anyway because the instances are expensive to create.

> P.S.  I added ThreadLocal to the libraries, and I had to fight hard to 
> get them in.  I have no doubt that I did the right thing when I added 
> them.  Yes, they're open to abuse, but so is everything else. 

  Sorry to piss in your cornflakes!

> </soapbox> 

  Or your soap flakes, or whatever.