On 21 January 2011 15:02, Caldarale, Charles R <chuck.caldar...@unisys.com> wrote: >> From: sebb [mailto:seb...@gmail.com] >> Subject: Re: bug in TC6 ContainerBase class? > >> There is no requirement for the compiler to reload variables unless >> the variable is volatile, or there is a shared lock between threads. > > Correct - with one caveat: if the compiler cannot prove there is no > synchronization, it must assume that there is.
Do you mean: * the compiler must assume that there is no synch, or * the compiler must assume that there is synch. I originally read your statement as the latter, but I think the former is correct, i.e. the compiler cannot assume there is any synch. > Also, the method calls can have side effects not discernible by the compiler, >including updating of fields not specified in the argument list. True. >> In the absence of volatile or sync. on a shared lock there is no >> guarantee that the updated threadDone variable will *ever* be seen by >> the background thread. > > Nope, it's required to be reloaded due to the constraints mentioned above. If any reloading is required, it surely only applies to the current thread. The JMM only guarantees as-if-sequential semantics for each thread independently, So as far as I can tell, calling non-synch. methods only affects compiler optimisation - it does not affect visibility of changes in other threads. >> In particular, in this case the compiler may notice that the >> threadDone variable is loop-invariant, and haul it out of the loop; >> see for example: >> >> http://java.dzone.com/articles/multithreading-and-java-memory >> >> In which case, the background thread run loop will never terminate. > > Note that in all the cited examples, there are no method calls inside the > loop. Point taken. > - Chuck > > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY > MATERIAL and is thus for use only by the intended recipient. If you received > this in error, please contact the sender and delete the e-mail and its > attachments from all computers. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
