[concurrency-interest] reusing threads and thread local state

Joshua Bloch jbloch at gmail.com
Sat Apr 30 13:40:22 EDT 2005


Honestly, my complexity meter is buried deep in the red.  Anything
that complex can't be good.  Regardless of whether it's sound, the
average bear coudln't make use of such a facility.

         Sorry to be so blunt,


On 4/29/05, Jeremy Manson <jmanson at cs.purdue.edu> wrote:
> Josh,
> When we were doing the memory model, we came across the need for a
> "final field safe context".  One of the guarantees it provides is that
> if you are in a thread that read an improperly published version of the
> object, and you enter a final field safe context, and you only see
> properly published versions of the object within that context, you will
> get your final field guarantees back.
> (For those not in the know: if Thread A is constructing an object and
> places a reference to it where another thread can see it (or "publishes"
> the reference) before the constructor finishes, and then Thread B reads
> that reference, Thread B isn't guaranteed to see the correct values for
> the final fields of that object.  If Thread A waits until the object is
> done constructing before publishing the reference, then Thread B is
> guaranteed to see the correct values for the final fields of that object.)
> I have often thought that some interface to final field contexts that
> also covers ThreadLocals should exist.  In effect, create a
> "runInLogicalThread" method that takes a Runnable, executes it in a
> final field safe context, and provides a "fresh slate" for the
> ThreadLocals.  When you return, the ThreadLocals are reset to their
> original values, and final fields are (potentially) no longer safe.
> I posted this idea to this list a year or two back, but it sort of
> fizzled.  I can't remember why now, though.  Now that people are
> thinking about final fields (a little), maybe it is time to think about
> it again?
> Or do you think this solution is as problematic as the idea of having a
> clear() method?
>                                         Jeremy
> Joshua Bloch wrote:
> > Pete,
> >
> > Oh no, not again. I fought this so many times over the years.  It's
> > one of those ideas that seems good on the surface but isn't.  My
> > analogy is used cars vs. new cars.  If you want a new car / thread,
> > you have have to pay a bit more for it.  If you go to a used car lot /
> > thread pool, the car may have a few dings on it / thread may have a
> > bit of state associated with it.  If you can live with this, buy a
> > used car / use a thread pool.  If not, buy a new car / create a
> > thread.
> >
> > Also, resetting ThreadLocal state does not produce a virgin thread.
> > There is other hidden state associated with a thread.  Some of it can
> > be external to the thread (e.g., it can be registered in a static data
> > structure). With threads as with people, you can only be a virgin
> > once.  Yow, are we mixing meaphors yet?
> >
> > Java has a powerful access control model.  It lets you write provably
> > correct programs.  Letting one thread muck with another's ThreadLocal
> > variables eats into this access model.  Just say no.
> >
> >        My 2 cents,
> >
> >        Josh

More information about the Concurrency-interest mailing list