On 21 January 2011 06:36, Caldarale, Charles R <chuck.caldar...@unisys.com> wrote: >> From: sebb [mailto:seb...@gmail.com] >> Subject: Re: bug in TC6 ContainerBase class? > >> What method calls will force a reload? Why must the compiler >> assume it has changed? > > Any other than Thread.sleep(). Again, we are discussing what happens in > practice, not in theory. Since the javac compiler does not, in this case, > have knowledge of the internal operations of the called methods, it must > pessimistically assume that synchronization may occur and fields have been > updated. (On the other hand, a JIT, with its runtime knowledge, could > determine whether or not synchronization happens and optimize out the reload. > But that would require either calls to very simplistic methods or a very > deeply probing JIT.) For methods that javac does have knowledge of (e.g., > Thread.sleep(), as defined by 17.9 of the language spec, or non-overridable > ones in the class), the compiler does not have to be pessimistic.
I really don't understand that. The JMM specifically allows for caching of variables in local memory or registers, and in the absence of synch. is only required to maintain as-if-sequential semantics for a single thread. There is no requirement for different threads to even maintain the same ordering, so long as each thread appears to be be sequential. There is no requirement for the compiler to reload variables unless the variable is volatile, or there is a shared lock between threads. So saying that the compiler must reload the value in the absence of volatile/synch goes against one of the principles of the JMM, which is to allow the compiler and JVM freedom to cache and re-order operations to improve performance. >> Surely that is what volatile is for? > > Volatile insures that ordering is observed in lieu of explicit > synchronization. Yes, it effectively ensures that the value written be one thread will be seen by another that executes later. 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. 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. > - 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
