[concurrency-interest] reusing threads and thread local state

Mike Skells mike.skells at ebizz-consulting.com
Thu May 5 16:28:29 EDT 2005

-----Original Message-----
From: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf Of Dawid
Sent: 05 May 2005 17:24
To: Mike Skells; concurrency-interest at altair.cs.oswego.edu
Cc: 'Gregg Wonderly'; larryr at saturn.sdsu.edu; 'Pete Soper'; 'Osvaldo Pinali
Doederlein'; gregg.wonderly at pobox.com
Subject: Re: [concurrency-interest] reusing threads and thread local state


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"
[Mike Skells] 
When your classes are unloaded, and not reloadable, then this is complicates
to the level of being impossible

>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.
[Mike Skells] 
Again this is more complexity, for no purpose. Do you believe that the
library will manage the threads for you.

The point is that the start of this email chain was looking to define/refine
a simple pattern to make life easier, and less error prone

>3. It stops the application being swapped
[Mike Skells] 
What does ? mean

Does it mean that you don't understand that the application cannot be
swapped, or that you don't think that this is an important ussue,
considering that you consider that this can be used and reused as a standard

>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.
[Mike Skells] 
Sorry, maybe I am reading too much into the comment
> 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.
Sounds like this is a easy to use general solution. I didn't see any careats
in the comment, hence my response

 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".
[Mike Skells] 
Agreed. The use case here is important. My usage pattern for threadLocals is
not looking for any enhancements here, I tend to use then for callbacks only
and the mechanism that I use cleanup on exit [not proposing this pattern!]

>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. 
[Mike Skells] 
After 1.5 they arefreed up when the thread exits

See Thread.exit()

[Mike Skells] 
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, ?>)
[Mike Skells] 
I think that one of us has missed the point here. The proposal was to
provide an alternative to ThreadLocal. So what do you need the HashMap for?

And of course this will _not_ work prior to JDK 1.5
[Mike Skells] 

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.


Concurrency-interest mailing list
Concurrency-interest at altair.cs.oswego.edu

More information about the Concurrency-interest mailing list