ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <ste...@apache.org>
Subject Re: race conditions in Ant
Date Fri, 05 Oct 2007 10:03:31 GMT
Peter Reilly wrote:
> 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.


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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message