[concurrency-interest] reusing threads and thread local state
mike.skells at ebizz-consulting.com
Thu May 5 16:28:29 EDT 2005
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
>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"
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.
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
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.
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".
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.
After 1.5 they arefreed up when the thread exits
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, ?>)
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
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.
Concurrency-interest mailing list
Concurrency-interest at altair.cs.oswego.edu
More information about the Concurrency-interest