--- 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.
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: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > ____________________________________________________________________________________ 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
