ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: race conditions in Ant
Date Fri, 05 Oct 2007 09:20:52 GMT
Matt Benson wrote:
> --- Steve Loughran <> 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
>>> "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

Which means you ought to clean them up when you are finished.

I've filed this as todo items @work

but not looked through ant's code, not yet

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message