Peter Reilly wrote:
On 10/5/07, Steve Loughran <[EMAIL PROTECTED]> wrote:
Matt Benson wrote:
--- Steve Loughran <[EMAIL PROTECTED]> wrote:
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.
Which code, Steve?
Any code that uses threadlocal needs to be looked at. You mustnt
subclass it and override the initialvalue method with one that itself
creates objects that may use threadlocal. If you leave it with a null
init value all is well, but once you start subclassing, you run a risk
of same-thread reentrant access to datastructures that, while thread
safe, are not locked against re-entrant operations
oh, lots of ambuiguity about ThreadLocal cleanup too: stuff in a
ThreadLocal can hang around for the life of a thread
Yes, this is the issue with IVY.
we could do a trick here under <subant>: start a new thread for each run
and have the original thread block until it exits. It wouldnt be
parallel, but it may clean up
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
