[concurrency-interest] Soliciting input about removeAllThreadLocals
Sun, 08 Dec 2002 15:14:17 -0600
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
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!
Or your soap flakes, or whatever.