ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Reilly" <peter.kitt.rei...@gmail.com>
Subject Re: race conditions in Ant
Date Fri, 05 Oct 2007 09:38:22 GMT
On 10/5/07, 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. 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.


>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6209042
>
> Which means you ought to clean them up when you are finished.

At least for threadlocals associated with long-lived threads. ThreadLocals
associated with threads that have ended should be GCed. (However
there may be bugs with this).

Peter

>
> 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
>
>

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


Mime
View raw message