[concurrency-interest] reusing threads and thread local state

Gregg Wonderly gregg at cytetech.com
Thu May 5 12:34:34 EDT 2005



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.  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.

I'm not sure what #3 refers to.  The application is J2SE compatible and 
can thus be run on any J2SE complient JVM.

> 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

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.

Gregg Wonderly


More information about the Concurrency-interest mailing list