On 10/5/07, Steve Loughran <[EMAIL PROTECTED]> wrote: > Matt Benson wrote: > > --- Steve Loughran <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
