[concurrency-interest] Soliciting input about removeAllThreadLocals

Joshua Bloch joshua.bloch@sun.com
Mon, 09 Dec 2002 14:27:33 -0800


>>   By the way, I don't really understand your beef with the current
>>thread local facility (which I happen to like much more than its
>>pthreads-era predecessors).
>  ^^^^^^^^^^^^^^^^^^^^^^^^^
>I'm just curious: why? AFAICS, the main difference is the addition
>of an extra state [used/non-used] to support initialValue() plus
>somewhat murky [suddenly we've got parents/childs among threads]
>"inheritability" on one hand, and on the other hand, the *lack* of
>destructors/cleanupors-if-you-like invoked at thread termination
>time; and in the context of terminating thread.
Nope.  You're missing the main point.  In pthreads (and in all 5 
home-brewed thread-local-storage solutions that I saw prior to designing 
ThreadLocal) explicit, forgeable keys were used to acess a thread-local 
variable.  In the case of pthread_getspecific it was the first argument 
(pthread_key_t key).  In the case of all the home-brewed solutions I saw 
(both inside and outside Sun!), people used strings as keys.  This is an 
awful idea, as all hell breaks loose when two people pick the same 
string, or when a hacker attempts to guess the key you used, to peak (or 
poke) at the data.  A simple fix would be to use unforgeable object keys 
(capabilities). The clever realization that makes the current design 
nice is that there's no need for a separate key object.  (This is 
discussed in a bit more detail on pages 152-154 of "Effective Java.")

> But that's it, so to speak. Or am I just missing
>and/or misunderstanding something? I'd say that "language" support
>ala sort-of-upcoming C/C++'s "__thread" storage [but that would also
>work with dynamic init and would be "fully lazy"] would be much more
>fun-to-use in many [but not all] cases.
I suggested this in '97, but the suggestion was met with lukewarm 
response.  The libary solution represents a compromise.

>Well, concerning the subject of this thread, I don't like removeAll-
Glad to hear it!



P.S.  I admit that InheritableThreadLocal was a bit speculative but I 
think it has proven useful to a number of people.