[concurrency-interest] Soliciting input about removeAllThreadLocals
Mon, 9 Dec 2002 16:32:59 +1000
> >I think this gets to the crux of the matter: thread-local versus
> >task-local. I can not imagine (other than for
> >purposes) a thread-local variable the value of which is *entirely*
> >independent of the task being executed by the thread, and which it
> >would thus be wrong to reset when commencing to execute a new task.
> I can. Keep in mind that the abstractions may be completely
> unrelated. Someone writes a little facility that uses
> ThreadLocal for some reason or other with no thought to tasks. Then
> gets called from a task.
Sorry but thats a vacuous example. What does the thread local do if it
is totally independent of any task the thread may execute.
> >I can easily imagine usage of thread-locals in a way that
> >are really
> >task-local and thus it would be wrong not to reset them when a new
> >task commences.
> In this sort of use, the ThreadLocal is generally updated
> manually in a finally block so there's no need ot reset.
You're assuming that the task knows ahead of time that it is using
thread locals. I am considering a task that uses a library and the
library utilises thread locals under the assumption that thread and
task are synonymous. The library initialises the thread local the
first time a task uses the library in that thread and then assumes
that subsequent uses by the same thread represent the same task. It is
an invalid assumption but the library has no way of knowing whether a
task and a thread are synonymous. An example would be a database
connection object, or security credentials, or customised
"properties". If ther person writing the task knows how the libraries
they will use themselves use thread local data then they may be able
to deal with the re-initialization issue, but otherwise they can't.
> I actually wrote a piece taxonomizing the uses of
> ThreadLocal many years ago when I campaigned to put them in the
> I'll try to dig it up. I think it would be more than a little bit
> entertaining to look at resets in the context of each usage.
That could be interesting.