[concurrency-interest] Soliciting input about removeAllThreadLocals

Vijay Saraswat vijay@saraswat.org
Mon, 09 Dec 2002 10:33:52 -0500

Joshua Bloch wrote:

> Vijay,
>> Having the underlying ThreadPool implementation for the servlet 
>> runner use a removeAllThreadLocals would not break this pattern. 
>   I would put this another way: this pattern would not benefit from a 
> "service" removes all thread locals -- it has no need of such a 
> service, because it takes care of its own thread locals.
>   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 understand that Java does not provide 
> any easy way to, for instance, use ThreadLocals to establish nested 
> dynamic scopes, but I think this is an orthogonal issue.
>             Regards,
>             Josh

Unfortunately I have a pressing NSF deadline on the 12th, so a fuller 
response will have to wait for that to pass.

In the meantime here are a couple of thoughts:

(1) ThreadLocal should be generic:

   public class ThreadLocal<A> {
      public A get();
      protected A initialValue();
      public void set(A value);
(I trust there is no problem in retrofitting this.)

(2) There is something really odd about ThreadLocal (an 
implementation-related notion) showing up in the program's type-space. I 
really would hate to see a public method return a ThreadLocal type! This 
should somehow "stay confined" within private state of a class -- but 
there is no linguistic structure in Java which will let the programmer 
express this. (In some sense "being ThreadLocal" is an attribute of a 
*variable*, shouldn't be confused with the type of the value stored in 
that variable.)

(2') And what exactly does holding a lock on a ThreadLocal accomplish? 
(I hate the idea of locks on java.lang.Object, but that is another 
story.) if being ThreadLocal is an attribute of a variable, this 
question would not arise.

(3) Yet another extension to the language via an API, yet another magic 
class* :-(. I hate magic classes --- makes it really hard to get a grip 
on the *language*. There is a lot of feature creep in Java via magic 
classes --- Threads, References, ThreadLocals, ClassLoaders, 
Serialization, stack crawling... If Java were being redesigned from 
scratch, would ThreadLocal be in there the way it is today?

Need to think through this more...


*A magic class is one which cannot be implemented generically for all 
JVMs, but must be dependent on the details of the JVM implementation.

PS: Twenty years, huh, since we exchanged email?

Prof Vijay Saraswat
Department of Computer Science and Engineering
Pond Laboratory
University Park, Pa 16802

calendar: http://calendar.yahoo.com/vjsaraswat
homepage: http://www.cse.psu.edu/gradbroc/faculty/saraswat.html
phone: +1.814.865.9505
eFax: +1.973.828.0442
aim, Yahoo IM, AT&T IM: vjSaraswat
MSN im: vijay@saraswat.org