[concurrency-interest] reusing threads and thread local state
dawidk at mathcs.emory.edu
Wed May 4 18:03:58 EDT 2005
Mike Skells wrote:
>>I don't use threadlocals myself because it is just as easy to use a
>>Hashtable<Thread,Hashtable<String,?>> via a static factory which I can
>>control access to and manage clearing etc on my own.
>Interesting to know how you manage the cleanup, as you now have a strong
>reference to a Thread in you HashMap, so the Thread cannot be GC until every
>one of your explicit cleanups completes
I guess WeakHashMap should do the trick.
There exists an alternative that actually uses thread locals, with
support for delegating them to worker threads. See
http://www.mathcs.emory.edu/dcl/util/#concurrent, paragraph on
delegatable thread locals.
The idea is that you can take immutable snapshot of the current thread's
state, including delegatable thread locals (user-level subclass of
InheritableThreadLocal), and later temporarily revert to that state,
usually in other (worker) threads:
ThreadContext cxt = ThreadContext.getContext(); // takes current
snapshot, including values of delegatable thread locals
// later, usually in a different thread
during the execution of the runnable, the state (e.g. values of
delegatable thread locals) of the thread in which "perform" was invoked
is set to the snapshot represented by the cxt. After returning from
"perform", state is fully restored to the original value.
This technique can be used in particular to run worker tasks in a
"pristine" environment, as was postulated (by using "empty" snapshots)
without violating encapsulation, without introducing race conditions,
and without resorting to explicit "clear" operation on thread locals.
Also, it can be used to propagate thread locals through executors from
invoking thread to the worker thread - the executor needs basically to
take thread snapshot on "execute" and use it during task execution.
Alternatively, it can be used to achieve state persistency between tasks
- all you need to do is to re-take the snapshot at the end of each task
and hand it in to the next task.
Of course it does not work for ordinary ThreadLocals and
InheritableThreadLocals - this can't be done without changing the JVM.
To make your thread locals delegatable you need to explicitly use
DelegatableThreadLocal class when you create them.
More information about the Concurrency-interest