Re: Proposed new Java feature
On 05/28/2012 05:28 PM, markspace wrote:
On 5/28/2012 3:13 AM, Robert Klemme wrote:
How can you know if you did not create the thread?
But we are creating the thread. It's part of a thread pool for general
use. That's his use case; it's the fundamental crux of his request.
Maybe there is a misunderstanding: I read your statement to mean that
"Sioux Unusual class" assumes the thread to be dead while it was created
by someone else (presumably the thread pool). So it cannot know
anything about thread creation and dead because it does not have any
control over the thread's lifetime.
I can think of a few scenarios where it would be useful to use both
thread locals and a thread pool, so while maybe "dangerous" it's still
something we should investigate properly.
It's certainly a useful idiom: the thread pool saves the overhead of
creating and destroying threads (and can also control the amount of
concurrency in an application) and ThreadLocals cache state which can be
accessed without synchronization overhead. Killing that every time a
thread returns to the pool will make caching much less efficient.
Hacks like the reflective code
I linked to earlier that dump private fields seem a lot more "dangerous"
to me, yet they are currently needed.
IMHO they are OK as long as they are used to log debugging warnings
during development but as I said, a general mechanism to clear all
thread locals does have more drawbacks than advantages. Now you are
hunting memory leaks through badly coded thread locals, then you might
have to hunt down weird application behavior because of state
disappearing which is expected to be still there. Remember that *any*
method in the thread's call stack can invoke cleaner which means that
all methods upwards the call stack will not find their ThreadLocals back
once control returns to them.
If we think about extending ThreadLocal's functionality at all then I
would think in the direction of registering a cleanup handle (callback
interface) with a ThreadLocal (or defining an empty method in
ThreadLocal which can be overridden). This handle would be invoked by
the Thread itself prior to termination but could also be invoked by a
thread pool or other framework. Even that functionality might introduce
bad bugs since - again - all methods on the call stack would be able to
invoke it. At least the creator of the ThreadLocal would have a chance
to detect the situation and report a proper error (illegalstate for
example).
Illustration
public class ThreadLocal<T> {
static class ThreadLocalMap {
private void remove(ThreadLocal<X> key) {
Entry[] tab = table;
int len = tab.length;
int i = key.threadLocalHashCode & (len-1);
for (Entry e = tab[i];
e != null;
e = tab[i = nextIndex(i, len)]) {
if (e.get() == key) {
// invoke cleanup code:
key.cleanup((X) e.value);
e.clear();
expungeStaleEntry(i);
return;
}
}
}
/**
* This method does nothing. Sub classes must override as they see fit.
* @param the value of a thread which must be cleared.
* @see #remove()
*/
protected void cleanup(T val) {
// nop
}
// Now we can even allow a cleanup all
public static removeAll() {
// pseudo code
for (final ThreadLocal<?> tl : allLocalsOfThisThread()) {
tl.remove();
}
}
}
However I think about it: the idea of simply clearing ThreadLocal
references still does not become a good idea. The creator of a
ThreadLocal needs to consider how it is used and how cleanup is done.
Everything else introduces dangerous side effects which lead to bugs
which are at least as hard to find as those memory leaks.
Kind regards
robert