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.
Obviously yes.
Aleksey, thanks for your response and presentation. I need to rethink a
whole JMM, unfortunately :(.
By the way, in your transcription you said:
int a;
volatile boolean ready = false;
void actor(IntResult1 r) {
while (!ready){};
r.r1 = a;
}
void observer() {
a = 41;
a = 42;
ready = true;
a = 43;
}
You said that possible values for r1 are 42 and 43. I cannot understand why
41 is impossible. What does prevent write(a, 41) and write(a, 42) from
being reordered?
JMM is a weak model. It means that JMM is allowed to reorder all normal
memory operations provided that reordered program is equivalent in
one-threaded environment. In my example I see nothing prevents reordering.
a = 42
a = 41
ready = true
a = 43
is equivalent to
a = 41;
a = 42;
ready = true;
a = 43;
W dniu środa, 16 maja 2018 19:49:04 UTC+2 użytkownik Aleksey Shipilev
napisał:
>
> 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 [email protected].
For more options, visit https://groups.google.com/d/optout.
