[concurrency-interest] reusing threads and thread local state
dawidk at mathcs.emory.edu
Thu May 5 12:24:06 EDT 2005
Mike Skells wrote:
>The point is that the approach that you propose is not suitable for the
>1. It doesn't work in J2EE
That's a strong claim, I haven't seen you demonstrated this; all you
said is that "cleanup is complicated"
>2. It doesn't work when you are writing reusable code (ie not the app)
If you are writing the library, you can specify how you handle
thread-specific data as a matter of your library API.
>3. It stops the application being swapped
>Given the above it does not seen to be a good idea to post is as the
>solution to the problem that was described.
I don't think Gregg posted it as a general solution - it seemed rather
as a possible approach that may be useful in some cases. Same with my
DelegatableThreadLocal proposal. But frankly, first of all, what is the
problem that was described, exactly? I think that the main reason why
the EG does not want to hear about thread locals is that nobody so far
have shown a valid use case in which their
cleanup/propagation/management was really needed. Everyone is speeking
in general terms, and speculating "what the world needs", but noone
managed to provided example like: "I wrote an application/library X, it
does Y and Z, and I need it to be able to do W, which is not possible
with existing API because Q".
>BTW WeakHashMap is _not_ a same management mechanism for the problem below.
>You are assuming that there in no reference to the Thread in any of the
>values that you maintain, or anywhere else in any system you ever write.
>This is precisely the problem that causes memory leaks
If you have references to the thread anywhere else in the system, your
thread locals will not be freed in any case. Yes, back-references from
values would also keep thread local map alive, but often you know that
your application does not have them. But, in fact, it can be fixed by
changing the outer map into an ordinary thread local:
new ThreadLocal(new HashMap<String, ?>)
In fact, this is a strategy I used in my ThreadContext class to
I agree that memory leaks may be a serious problem in Java apps.
Fortunately, with existing profilers, they are usually quite easy to
identify and fix.
More information about the Concurrency-interest