ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@yahoo.com>
Subject Re: race conditions in Ant
Date Fri, 05 Oct 2007 14:22:23 GMT

--- Steve Loughran <stevel@apache.org> wrote:

> Matt Benson wrote:
> > --- Steve Loughran <stevel@apache.org> 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.

Oh--for some reason I had gotten the impression from
your previous message that there was some particular
piece of code at which you had already looked.

-Matt

> 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
> 
>
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6209042
> 
> Which means you ought to clean them up when you are
> finished.
> 
> I've filed this as todo items @work
> http://jira.smartfrog.org/jira/browse/SFOS-469
> http://jira.smartfrog.org/jira/browse/SFOS-470
> 
> but not looked through ant's code, not yet
> -Steve
> 
> 
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@ant.apache.org
> For additional commands, e-mail:
> dev-help@ant.apache.org
> 
> 



       
____________________________________________________________________________________
Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories
at Yahoo! Games.
http://sims.yahoo.com/  

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message