[concurrency-interest] reusing threads and thread local state

Dawid Kurzyniec 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.
>>    
>>
>
>[Mike Skells] 
>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
cxt.perform(Runnable);

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.

Regards,
Dawid




More information about the Concurrency-interest mailing list