Re: About the volatile and MESI Protocal
Alex Otenko via Concurrency-interest <[email protected]> Mon, 21 Feb 2022 15:41:56 +0000
| Newsgroups | gmane.comp.java.jsr.166-concurrency |
|---|---|
| Message-ID | <CANkgWKhg1nHRwD2KmppAz9Vkj0Ckze8oYYnqkiFfE_S6dbe3YA@mail.gmail.com> |
--===============1691605106938558695== Content-Type: multipart/alternative; boundary="0000000000003d933005d8891305" --0000000000003d933005d8891305 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This lengthy argument falls apart, once you realize that its premise is false. That is, the premise that every software system has a total order. Alex On Mon, 21 Feb 2022, 14:06 Gregg Wonderly via Concurrency-interest, < [email protected]> wrote: > The problem is that Java and many other languages are not safe in a > multithreaded environment to start with. The memory model is safe for a > single thread. This all goes back to the attempts by Sun and other membe= rs > of the Java EE landscape trying to make that platform the most performant > environment to sell more hardware. Sun had the weakest memory model that > could only be able to actually be faster if all of these JMM designs were > available. > > Again, the problem is the hardwares poor performance in sharing data > safely between cores. Because the software systems do not do full data fl= ow > analysis and instead do micro analysis, the visibility of all references > and all writes is not understood and so we have these guessing based > optimizations. > > There is always a total order to any software system. Those with externa= l > inputs make it even harder to know what the total order might be. My > standing example of where hoisting doesn=E2=80=99t work is a perfect exam= ple of how > micro analysis just doesn=E2=80=99t work. > > The document I linked to showing many examples of why final or volatile > are needed on class local declarations illustrates how prevalent software > broken by the non-volatile default definition in Java has created large > amounts of time wasting architecture and the exact hand optimization and > manipulation you say should not be necessary. > > Speed is rarely the first choice of software engineering. Profiling can > provide great insight into hotspots in software systems. Letting the > developer solve only the problems that are important to them, and not > providing them additional problems to solve seems like the better choice! > > Gregg Wonderly > > Sent from my iPhone > > > On Feb 20, 2022, at 6:26 AM, Aleksey Shipilev via Concurrency-interest = < > [email protected]> wrote: > > > > =EF=BB=BFOn 2/19/22 13:30, Florian Weimer via Concurrency-interest wrot= e: > >> * Nathan Reynolds via Concurrency-interest: > >>> Without volatile or fences, JIT is free to hoist the "if (bChanged = =3D=3D > >>> !bChanged)" out of the for loop. If for some reason JIT decides to n= ot > >>> hoist, JIT could also load bChanged into a single register each > iteration > >>> and then execute "if (bChanged =3D=3D !bChanged)" using the value in = the > single > >>> register. On the other hand, if JIT is smart enough, it can get rid > of the > >>> if statement and block altogether since it can never be true accordin= g > to > >>> the Java Memory Model. Since this is very unlike a real code > scenario, I > >>> doubt JIT has been enhanced for this last case. > >> I don't think this is a property of the memory model, it merely > >> follows from choices Java implementation have made regarding compiler > >> barriers for volatile field access. > > > > AFAIU, progress guarantee is where the current memory models, as stated > in JLS, is quite murky. This one of those abyss-mal places where the long= er > you look, the creepier it gets. The major problem there is tying up both > writer and loop-reader into the behavior we intuitively want. It is a rea= l > hard thing to specify without losing sanity. > > > > You can show the lack of progress guarantees for "while (field) {}" loo= p > executing alone, by the virtue of saying "there is an JMM execution that > never observes the store to `field`". Note it ties up the notion that the= re > is a write to "field", and it is ordered "after" all reads. > > > > AFAICS, the same thing could be said when "field" is volatile: a > Sufficiently Smart^W Evil Optimizer (tm) can say, "Yes, volatile actions > are in total order, and I decide that the order we are dealing with in th= is > particular micro-test is where the write to field at the end of that tota= l > order; thus no reads observe it, and I can yank the field load out of the > loop". The totality of synchronization order really buys us nothing in th= is > example, except for scaring the less smart/evil optimizers into not doing > anything that touches synchronization actions. > > > > C/C++ spec talks about progress guarantees, where "Implementations > should ensure that all unblocked threads eventually make forward progress= " > and "An implementation should ensure that the last value (in modification > order) assigned by an atomic or synchronization operation will become > visible to all other threads in a finite period of time". But AFAIU, > "should" =3D "recommended" in that text. Hans Boehm et al. wrote why it i= s > not a hard requirement here: > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3152.html > > > > Java makes a significant step towards that by saying that "Opaque" and > stronger modes guarantee progress, but that again is not part of the form= al > JLS. See "Opaque mode" properties here: > > http://gee.cs.oswego.edu/dl/html/j9mm.html > > > > -- > > Thanks, > > -Aleksey > > > > _______________________________________________ > > Concurrency-interest mailing list > > [email protected] > > http://cs.oswego.edu/mailman/listinfo/concurrency-interest > > _______________________________________________ > Concurrency-interest mailing list > [email protected] > http://cs.oswego.edu/mailman/listinfo/concurrency-interest > --0000000000003d933005d8891305 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div dir=3D"auto">This lengthy argument falls apart, once= you realize that its premise is false. That is, the premise that every sof= tware system has a total order.</div><div dir=3D"auto"><br></div><div dir= =3D"auto"><br></div><div dir=3D"auto">Alex</div><div dir=3D"auto"></div><di= v dir=3D"auto"><br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" cl= ass=3D"gmail_attr">On Mon, 21 Feb 2022, 14:06 Gregg Wonderly via Concurrenc= y-interest, <<a href=3D"mailto:[email protected]" targe= t=3D"_blank" rel=3D"noreferrer">[email protected]</a>> = wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e= x;border-left:1px #ccc solid;padding-left:1ex">The problem is that Java and= many other languages are not safe in a multithreaded environment to start = with.=C2=A0 The memory model is safe for a single thread.=C2=A0 This all go= es back to the attempts by Sun and other members of the Java EE landscape t= rying to make that platform the most performant environment to sell more ha= rdware.=C2=A0 Sun had the weakest memory model that could only be able to a= ctually be faster if all of these JMM designs were available.<br> <br> Again, the problem is the hardwares poor performance in sharing data safely= between cores. Because the software systems do not do full data flow analy= sis and instead do micro analysis, the visibility of all references and all= writes is not understood and so we have these guessing based optimizations= .<br> <br> There is always a total order to any software system.=C2=A0 Those with exte= rnal inputs make it even harder to know what the total order might be.=C2= =A0 My standing example of where hoisting doesn=E2=80=99t work is a perfect= example of how micro analysis just doesn=E2=80=99t work.<br> <br> The document I linked to showing many examples of why final or volatile are= needed on class local declarations illustrates how prevalent software brok= en by the non-volatile default definition in Java has created large amounts= of time wasting architecture and the exact hand optimization and manipulat= ion you say should not be necessary.<br> <br> =C2=A0Speed is rarely the first choice of software engineering.=C2=A0 Profi= ling can provide great insight into hotspots in software systems.=C2=A0 Let= ting the developer solve only the problems that are important to them, and = not providing them additional problems to solve seems like the better choic= e!<br> <br> Gregg Wonderly<br> <br> Sent from my iPhone<br> <br> > On Feb 20, 2022, at 6:26 AM, Aleksey Shipilev via Concurrency-interest= <<a href=3D"mailto:[email protected]" rel=3D"noreferre= r noreferrer" target=3D"_blank">[email protected]</a>> = wrote:<br> > <br> > =EF=BB=BFOn 2/19/22 13:30, Florian Weimer via Concurrency-interest wro= te:<br> >> * Nathan Reynolds via Concurrency-interest:<br> >>> Without volatile or fences, JIT is free to hoist the "if = (bChanged =3D=3D<br> >>> !bChanged)" out of the for loop.=C2=A0 If for some reason= JIT decides to not<br> >>> hoist, JIT could also load bChanged into a single register eac= h iteration<br> >>> and then execute "if (bChanged =3D=3D !bChanged)" us= ing the value in the single<br> >>> register.=C2=A0 On the other hand, if JIT is smart enough, it = can get rid of the<br> >>> if statement and block altogether since it can never be true a= ccording to<br> >>> the Java Memory Model.=C2=A0 Since this is very unlike a real = code scenario, I<br> >>> doubt JIT has been enhanced for this last case.<br> >> I don't think this is a property of the memory model, it merel= y<br> >> follows from choices Java implementation have made regarding compi= ler<br> >> barriers for volatile field access.<br> > <br> > AFAIU, progress guarantee is where the current memory models, as state= d in JLS, is quite murky. This one of those abyss-mal places where the long= er you look, the creepier it gets. The major problem there is tying up both= writer and loop-reader into the behavior we intuitively want. It is a real= hard thing to specify without losing sanity.<br> > <br> > You can show the lack of progress guarantees for "while (field) {= }" loop executing alone, by the virtue of saying "there is an JMM= execution that never observes the store to `field`". Note it ties up = the notion that there is a write to "field", and it is ordered &q= uot;after" all reads.<br> > <br> > AFAICS, the same thing could be said when "field" is volatil= e: a Sufficiently Smart^W Evil Optimizer (tm) can say, "Yes, volatile = actions are in total order, and I decide that the order we are dealing with= in this particular micro-test is where the write to field at the end of th= at total order; thus no reads observe it, and I can yank the field load out= of the loop". The totality of synchronization order really buys us no= thing in this example, except for scaring the less smart/evil optimizers in= to not doing anything that touches synchronization actions.<br> > <br> > C/C++ spec talks about progress guarantees, where "Implementation= s should ensure that all unblocked threads eventually make forward progress= " and "An implementation should ensure that the last value (in mo= dification order) assigned by an atomic or synchronization operation will b= ecome visible to all other threads in a finite period of time". But AF= AIU, "should" =3D "recommended" in that text. Hans Boeh= m et al. wrote why it is not a hard requirement here:<br> >=C2=A0 <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/20= 10/n3152.html" rel=3D"noreferrer noreferrer noreferrer" target=3D"_blank">h= ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3152.html</a><br> > <br> > Java makes a significant step towards that by saying that "Opaque= " and stronger modes guarantee progress, but that again is not part of= the formal JLS. See "Opaque mode" properties here:<br> >=C2=A0 <a href=3D"http://gee.cs.oswego.edu/dl/html/j9mm.html" rel=3D"no= referrer noreferrer noreferrer" target=3D"_blank">http://gee.cs.oswego.edu/= dl/html/j9mm.html</a><br> > <br> > -- <br> > Thanks,<br> > -Aleksey<br> > <br> > _______________________________________________<br> > Concurrency-interest mailing list<br> > <a href=3D"mailto:[email protected]" rel=3D"noreferre= r noreferrer" target=3D"_blank">[email protected]</a><br> > <a href=3D"http://cs.oswego.edu/mailman/listinfo/concurrency-interest"= rel=3D"noreferrer noreferrer noreferrer" target=3D"_blank">http://cs.osweg= o.edu/mailman/listinfo/concurrency-interest</a><br> <br> _______________________________________________<br> Concurrency-interest mailing list<br> <a href=3D"mailto:[email protected]" rel=3D"noreferrer nor= eferrer" target=3D"_blank">[email protected]</a><br> <a href=3D"http://cs.oswego.edu/mailman/listinfo/concurrency-interest" rel= =3D"noreferrer noreferrer noreferrer" target=3D"_blank">http://cs.oswego.ed= u/mailman/listinfo/concurrency-interest</a><br> </blockquote></div></div> --0000000000003d933005d8891305-- --===============1691605106938558695== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Concurrency-interest mailing list [email protected] http://cs.oswego.edu/mailman/listinfo/concurrency-interest --===============1691605106938558695==--