[concurrency-interest] reusing threads and thread local state

Dawid Kurzyniec dawidk at mathcs.emory.edu
Thu May 5 12:24:06 EDT 2005


Mike,

Mike Skells wrote:

>The point is that the approach that you propose is not suitable for the
>general case.
>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 
implement DelegatableThreadLocals.

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.

Regards,
Dawid




More information about the Concurrency-interest mailing list