On 05/16/2018 07:33 PM, John Hening wrote: > Subject: JMM- conservative and formal point of view.
There is no "conservative" JMM point of view. There is JSR 133 Cookbook for Compiler Writers that describes the conservative implementation, but it is not the JMM itself. Reductio ad absurdum: suppose JSR 133 Fanfic for Concurrency Experts would say the easy way to be JMM conformant is to acquire lock before entering any thread -- basically implementing Global Interpreter Lock. Would you be willing to take the existence of GIL in some implementations as the guidance for writing reliable software? I hope not. > 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. Double negation is confusing here. That slide points out that roach motel semantics basically says that some transformations are easy (putting stuff "into" the acq/rel block), and others are still possible, but hard. There are cases where it is not hard, actually: for example, when we know the access is provably thread-local. > 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. Caveat: when the *outcome* would be equivalent to some allowed JMM execution. It does not mean the actual implementation should issue machine instructions in any given order. > 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? No. The fluff about barriers is implementation details, which gets confusing very quickly as implementations screw with your code. I ranted about this a week ago at GeeCON: https://shipilev.net/talks/geecon-May2018-jmm.pdf -Aleksey -- 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.
signature.asc
Description: OpenPGP digital signature
