[concurrency-interest] reusing threads and thread local state
mike.skells at ebizz-consulting.com
Thu May 5 16:44:59 EDT 2005
From: Gregg Wonderly [mailto:gregg at cytetech.com]
Sent: 05 May 2005 17:35
To: Mike Skells
Cc: gregg.wonderly at pobox.com; 'Gregg Wonderly'; larryr at saturn.sdsu.edu;
concurrency-interest at altair.cs.oswego.edu; 'Osvaldo Pinali Doederlein';
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
> 2. It doesn't work when you are writing reusable code (ie not the app)
> 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.
The whole world is not J2EE powered. The fact that J2EE isolates you
from some of the capabilities of the J2SE platform is a completely
But the point remains - this pattern does not work in this case, so it in
not general. This is the point that I was making ie " not suitable for the
Regarding #2, I don't think I provided any concrete
code that what I wrote which showed that I was not creating reusable
code. If you interpreted it that way, I'm sorry for confusing you. I
do create reusable code where that makes sense. In some cases it's not,
because the application has some very specific needs.
Please see other email thread
I'm not sure what #3 refers to. The application is J2SE compatible and
can thus be run on any J2SE complient JVM.
Swapped not ported. Ie swapped out as a process from memory when the
application is quiet, and the OS has other demands on the system resources
> BTW WeakHashMap is _not_ a same management mechanism for the problem
> 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
I didn't suggest WeakHashMap as a 'same management mechanism'.
WeakHashMap is a useful mechanism only where the key can not be
referenced by external, uncontrolled sources. Global objects, such as
Thread are in fact, poor choices. The mechanism that I posted about in
an earlier note uses a separate object as the key. This eliminates the
global data view conflict as long as accessibility to that object is
Agreed, my comment relates only to 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.
I guess WeakHashMap should do the trick.
More information about the Concurrency-interest