[concurrency-interest] Soliciting input about removeAllThreadLocals
Sun, 08 Dec 2002 21:57:15 -0800
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
> 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
>> 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.
: ) No need to apologize. I'm just standing up for my progeny.