[concurrency-interest] Soliciting input about removeAllThreadLocals

Alexander Terekhov TEREKHOV@de.ibm.com
Mon, 9 Dec 2002 15:37:27 +0100


Joshua Bloch wrote:
[...]
>    By the way, I don't really understand your beef with the current
> thread local facility (which I happen to like much more than its
> pthreads-era predecessors).
  ^^^^^^^^^^^^^^^^^^^^^^^^^

I'm just curious: why? AFAICS, the main difference is the addition
of an extra state [used/non-used] to support initialValue() plus
somewhat murky [suddenly we've got parents/childs among threads]
"inheritability" on one hand, and on the other hand, the *lack* of
destructors/cleanupors-if-you-like invoked at thread termination
time; and in the context of terminating thread. Oh, sure, and Java
doesn't seem to have only-128-guaranteed limit imposed on the number
its thread locals. But that's it, so to speak. Or am I just missing
and/or misunderstanding something? I'd say that "language" support
ala sort-of-upcoming C/C++'s "__thread" storage [but that would also
work with dynamic init and would be "fully lazy"] would be much more
fun-to-use in many [but not all] cases.

Well, concerning the subject of this thread, I don't like removeAll-
thing. I'd probably could/want-to live with an EXCEPTION that would
kinda "renew"/"reincarnate" a thread raising it [and propagating it
out of its thread routine]. The idea is that the same thread could
be "re-launched" using "old" or perhaps even newly specified [via an
exception object] thread routine{/argument(s)}. I'd personally have
no problem if ALL thread locals would become "removed" as part of
THAT ["exception-driven"] operation...

regards,
alexander.


Joshua Bloch <joshua.bloch@sun.com>@cs.oswego.edu on 12/07/2002 04:50:55 PM

Sent by:    concurrency-interest-admin@cs.oswego.edu


To:    Vijay Saraswat <vijay@saraswat.org>
cc:    Doug Lea <dl@altair.cs.oswego.edu>,
       concurrency-interest@altair.cs.oswego.edu
Subject:    Re: [concurrency-interest] Soliciting input about
       removeAllThreadLocals


Vijay,

>
> Having the underlying ThreadPool implementation for the servlet runner
> use a removeAllThreadLocals would not break this pattern.

   I would put this another way: this pattern would not benefit from a
"service" removes all thread locals -- it has no need of such a service,
because it takes care of its own thread locals.

   By the way, I don't really understand your beef with the current
thread local facility (which I happen to like much more than its
pthreads-era predecessors).  I understand that Java does not provide any
easy way to, for instance, use ThreadLocals to establish nested dynamic
scopes, but I think this is an orthogonal issue.

             Regards,

             Josh


_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@altair.cs.oswego.edu
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest