[concurrency-interest] Soliciting input about removeAllThreadLocals

Doug Lea dl@cs.oswego.edu
Sun, 8 Dec 2002 16:47:53 -0500


Luke wrote:

>   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?

I don't think so.

As Josh Bloch put it, creating a new thread is like buying a new car,
and reusing a worker thread in a pool is like buying a used car -- you
save on the up-front depreciation, but might find some existing
scratches. We'd like ThreadExecutor to be a top-notch used car lot
though.  (In fact, it now offers new cars too!  See factory method
newThreadPerTaskExecutor.)

And as EG member Tim Peierls added, about ThreadLocals:
  And ThreadLocal is an odometer. My car comes with two trip odometers,
  complete with reset buttons, in addition to the official non-resettable
  odometer. I don't have a "reset all trip odometers" button, and I don't
  need one.

> Why not have the JVM 
> in charge of thread pooling, multiplexing Java threads across native 
> threads as it sees fit? 

Similar strategies have tended not to work out well in other systems
(for example most implementations of Unix AIO) because of the lack of
controllability. ThreadExecutor has a lot of tuning options and
controls. Most people will never use them, but those that do will need
them to obtain good performance.

-Doug