[concurrency-interest] reusing threads and thread local state

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

-----Original Message-----
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';
'Pete Soper'
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 
different issue.  
[Mike Skells] 
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
general case."

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.
[Mike Skells] 
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.
[Mike Skells] 
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 
managed effectively/correctly.
[Mike Skells] 
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.

Gregg Wonderly

More information about the Concurrency-interest mailing list