[concurrency-interest] Soliciting input about removeAllThreadLocals

David Holmes dholmes@dltech.com.au
Mon, 9 Dec 2002 12:31:48 +1000


Vijay Saraswat wrote:
> In other words, there are legitimate reasons for keeping some
> state on a Thread whose extent spans the use of the Thread to
service
> a particular task.

I think this gets to the crux of the matter: thread-local versus
task-local. I can not imagine (other than for introspection/debugging
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 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 between I can imagine a situation where the threads in a particular
thread pool are not "pristine" but have been pre-initialized to
account for the context in which they are used - and that
pre-initialization may well involve state maintained in thread-locals
and thus it would be wrong to reset that state upon execution of a new
task. I would call this a "task-in-context".

And probably there are other distinctions that could be made.

David Holmes