The following picture comes from: https://shipilev.net/blog/2014/jmm-pragmatics/
<https://shipilev.net/blog/2014/jmm-pragmatics/page-101.png> As I understand this slide points that JMM does not constitute that a volatile write does not work as a (Load/Store)Store barrier, and it doesn't in fact. But, JVM is allowed to reorder a such situation only in special cases, when the execution will be *equivalent as if write(x,1) wouldn't be reorderd with release(g)*. In another words, here that reordering is allowed if and only if JVM is able to prove that it is equivalent to the situation without reordering. The question is: So, for considering *correctness* of program (and only *correctness*) can we assume that volatile store works as (Load/Store)Store barrier in fact? However, a such simpilified view doesn't explain why JVM is able in some cases to hostile: volatile x; for(..) x += 1; What do you think? -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
