[concurrency-interest] reusing threads and thread local state

Mike Skells mike.skells at ebizz-consulting.com
Fri May 6 11:19:24 EDT 2005



-----Original Message-----
From: Dawid Kurzyniec [mailto:dawidk at mathcs.emory.edu] 
Sent: 06 May 2005 00:01
To: Mike Skells
Cc: concurrency-interest at altair.cs.oswego.edu
Subject: Re: [concurrency-interest] reusing threads and thread local state

Mike Skells wrote:

>-----Original Message-----
>From: concurrency-interest-bounces at cs.oswego.edu
>[mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf Of Dawid
>Kurzyniec
>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,
>
>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
>
>  
>
I guess you are implying that memory leaks are nearly impossible to 
avoid when using the technique described by Gregg in J2EE.
[Mike Skells] 
Yes - put better than I did

>>3. It stops the application being swapped
>>    
>>
>?
>[Mike Skells] 
>What does ? mean
>  
>
I meant that I did not understand the sentence, because "swapped" is too 
ambigious. From the other thread, I understand that you meant swapping 
from memory to disk. I still do not see obvious connection between this 
and what Gregg suggested, other than hidden assumption that there must 
be some sort of a memory leak, but even then, I guess I can hardly see 
how it prevents swapping to disk. It may be my ignorance of J2EE though 
- perhaps you mean some J2EE-level swapping, not the OS-level swapping.

[Mike Skells] 
In other replies an indication that the cleanup task operates as a periodic
event, thus the application is activates to do the tidyup. If this is too
long then memory is tied up, if not then to OS cannot swap the task as it
keeps waking up



>>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
>  
>
OK, I think (hope?) we may all agree that the pattern proposed by Gregg 
is not a general-purpose replacement for thread locals; there are 
contexts where they are definitely more natural to use, e.g. since they 
provide better encapsulation, they avoid naming clashes, and they are 
faster. IMHO, though, that pattern can be useful in some situations, 
e.g. when you need named locals, when you need some sharing between 
threads, and when you need more dynamic creation patterns. In yet other 
cases, a hybrid solution (e.g. new ThreadLocal(new HashMap()) may be the 
most beneficial, since it preserves thread isolation while allowing 
dynamic instantiation.

I would like to read Gregg's posting as "in fact, we still could live 
even without normal thread locals; hence, we can live without JSR166 API 
extensions to clear them etc.", which does not imply that we should 
abandon thread locals, as in many contexts they are very nice and useful.

[Mike Skells] 
Agreed
>  
>
>>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()
>  
>
Acknowledged.

Regards,
Dawid






More information about the Concurrency-interest mailing list