[concurrency-interest] Soliciting input about removeAllThreadLocals

Luke Blanshard blanshlu@netscape.net
Mon, 09 Dec 2002 11:43:22 -0500

Joshua Bloch <joshua.bloch@sun.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/