[concurrency-interest] Soliciting input about removeAllThreadLocals
Mon, 09 Dec 2002 11:43:22 -0500
Joshua Bloch <email@example.com> wrote:
> 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.
Don't beat yourself up. More of a lighter than a blowtorch!
>> 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.
I guess we're talking at cross purposes here. I'm not worried about thread safety, I'm worried about good design -- i.e., writing code that isn't going to have those subtle bugs that Doug was talking about. (Though Lord knows, I probably should be worried about thread safety! The code I've seen...)
I think Miles Sabin put my position rather well: that "genuine thread context" is often tantamount to "sleazery". The era of the Globals Are Bad dictum was single-threaded C/C++, and he wasn't just talking about public globals, he was talking about variables of global extent. Holding context from one call to the next -- "current rounding mode" is a good example -- is a dangerous thing to do. A simple rearranging of code far removed can suddenly have mysterious consequences: the same call yields different results, because the current rounding mode is different here than it was two lines earlier.
>... The one point on which there's
>dissension is the need for Thread.removeAllThreadLocals(); I'm in the
>"over my dead body" camp : )
Sounds like everyone's in that camp. But that camp is itself divided among the "we need it" and the "we don't".
I guess I'm wondering about Doug Lea's assertion that it's not worth having two flavors of ThreadLocal, one that gets reset for each "lightweight task" and one that doesn't. Again, I think in general that it's better to explicitly pass around task-specific context than to use thread-locals for this, but I can imagine cases where I'd want to keep data under the covers, and treat each task as a separate instance. Logging might be an example. And likewise I can imagine cases where it's the thread itself that I want to shadow rather than the current task. What exactly is the matter with providing both options?
The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp
Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/