On 15/09/2015 22:55, Yilong Li wrote: > Fine. Let's do your example: > T2R4 (out of order read returns null) > T1R1 (returns null) > T1W2 (writes non-null value) > T1R4 (reads new non-null value) > T2R1 (reads new non-null value) > > First of all, when reasoning with JMM, you should not move T2R4 to the > front. This is forbidden by the intra-thread semantics so I move it back to > the bottom: > T1R1 (returns null) > T1W2 (writes non-null value) > T1R4 (reads new non-null value) > T2R1 (reads new non-null value) > T2R4 (out of order read returns null) > > Intra-thread semantics ensures the following HB order: > T1R1 < T2W2 < T1R4 > T2R1 < T2R4
I assume you mean: T1R1 < T*1*W2 < T1R4 above > T2R4 is allowed to read null because 1) T2R4 is not ordered before the > write of null (let's call it INIT) by JVM during object initialization; and > 2) there is no intervening write w' such that INIT < w' < T2R4. You see, > T1W2 is *not* an intervening write because there is no HB order between > T1W2 & T2R4. > > Let me know if it is still not clear enough. Sorry, still not clear enough. I understand that the JMM allows this behaviour. I don't understand how this could happen in a JVM implementation. If T2R1 has read a non-null value how could a T2R4, a read from the same thread that happens at some later point in time, read a previous value for the same field? That would imply that the two reads were implemented differently since they would have to be looking at different memory locations. What is going on here? Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
