[concurrency-interest] reusing threads and thread local state
mike.skells at ebizz-consulting.com
Fri May 6 11:19:24 EDT 2005
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:
>From: concurrency-interest-bounces at cs.oswego.edu
>[mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf Of Dawid
>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 Skells wrote:
>>The point is that the approach that you propose is not suitable for the
>>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"
>When your classes are unloaded, and not reloadable, then this is
>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.
Yes - put better than I did
>>3. It stops the application being swapped
>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.
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.
>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
>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
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
>>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.
>After 1.5 they arefreed up when the thread exits
More information about the Concurrency-interest