Steve Loughran wrote:
I've been running the new build and havent seen any more loops; I think
race conditions are gone.
Incidentally, given we didnt see any way that the thing could loop,
given we were using threadlocal to store a per-thread datastructure, and
given that threadlocals are implicitly thread safe, I'm still not sure
where the problem arose. but I have been pointed at some bugs in
ThreadLocal
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6550283
"ThreadLocal.initialValue() may be called multiple times in some cases"
There is a bit of a race condition on initialisation, *across all
threadlocal classes in use in that thread*. if you are only using your
own classes, you need to sync off something common (like the current
thread). But you are still vulnerable to any other class using Thread
local storage making an operation that increases the size of the hash
table of threadlocal values, in which case you are stuffed.
This is a WONTFIX for Java<1.6.
Accordingly, you can't reliably use ThreadLocal on a multicpu system for
Java <=1.5 as you cannot be sure that other classes wont stamp on you.
This is pretty serious, as the reason you would use TLS is to avoid
concurrency problems.
followup based on looking at the code.
Its not a race condition, so much as a re-entrancy bug. the code here is
thread safe, but doesnt lock out the per-thread hashmap while
initialising a ThreadLocal instance. If the thing being initialised is
subclassed to make a complex initial value, and that initial value
itself creates ThreadLocal content, then you are in trouble. If you dont
do that, you should be ok.
This is probably not the cause of the looping I saw.
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
