[concurrency-interest] reusing threads and thread local state

Dawid Kurzyniec dawidk at mathcs.emory.edu
Thu May 5 19:00:39 EDT 2005


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.

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

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

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