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 Thu, 04 Oct 2007 13:39:27 GMT
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.

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.


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

View raw message