[concurrency-interest] Soliciting input about removeAllThreadLocals

Joshua Bloch joshua.bloch@sun.com
Sun, 08 Dec 2002 21:57:15 -0800


Luke,

   Sorry for the flame.  I didn't mean to get so nasty : (   It's one of 
those things that I've been arguing for years.

>
>  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.

   No less code, but each thread is isolated from all other threads.  If 
you have a package-private static Integer HashMap, each thread can see 
the changes made by other threads.  If it's a (final) ThreadLocal 
containing a HashMap, each thread gets its own HashMap and the threads 
are independent.

>   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.

   This is only true for public static ThreadLocals.  Private static 
ThreadLocals  are generally safe as milk.

>
>>>  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 expensive. 

   I'm with you.  Thread pooling is a *necessary* evil.

> 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? 

Nope.  As Doug says, we all agree.  The one point on which there's 
dissension is the need for Thread.removeAllThreadLocals();  I'm in the 
"over my dead body" camp : )

>  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?  

   As Doug says, this sounds good in theory, but it's been tried and it 
doesn't work.

>
>> 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. 

: )  No need to apologize.  I'm just standing up for my progeny.

              Regards,

              Josh