> 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. Also, the method calls can have side effects not discernible by the compiler, including updating of fields not specified in the argument list. > 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. > 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. - 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
