Re: Are there real use cases with the Java access modes?
Alex Otenko via Concurrency-interest <[email protected]> Fri, 23 Jul 2021 20:31:47 +0100
| Newsgroups | gmane.comp.java.jsr.166-concurrency |
|---|---|
| Message-ID | <CANkgWKhHk1moZTkVJMgKq+GBLbQJt9qzjHK5dGWOOEdXDhsb9w@mail.gmail.com> |
--===============2280934204692152293== Content-Type: multipart/alternative; boundary="0000000000000fbb1905c7cf759b" --0000000000000fbb1905c7cf759b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 23 Jul 2021, 16:24 Gregg Wonderly, <[email protected]> wrote: > > > > On Jul 23, 2021, at 4:14 AM, Andrew Dinn via Concurrency-interest < > [email protected]> wrote: > > > > On 23/07/2021 04:36, Gregg Wonderly via Concurrency-interest > > > >> Truly, it takes pretty extreme expertise and experience to truly > >> understand how to [use Java to] do concurrent programming. > > > > Let's just note that if you take out the bracketed phrase that statemen= t > still remains true. > > I added that phrase because my experience with concurrency inside of Java > programs is the largest exposure I have. But that is dated compared to m= y > use of multi-threaded application in C/C++ that I=E2=80=99ve recently bee= n involved > in. In those cases, there is no worry about non-volatile hoisting doesn= =E2=80=99t > occur at all. I am sorry to burst your bubble... http://eel.is/c++draft/intro.progress Quote: The implementation may assume that any thread will eventually do one of the following: - (1.1) <http://eel.is/c++draft/intro.progress#1.1> terminate, - (1.2) <http://eel.is/c++draft/intro.progress#1.2> make a call to a library I/O function, - (1.3) <http://eel.is/c++draft/intro.progress#1.3> perform an access through a volatile glvalue, or - (1.4) <http://eel.is/c++draft/intro.progress#1.4> perform a synchronization operation or an atomic operation. <http://eel.is/c++draft/intro.progress#1.sentence-1> [*Note 1 <http://eel.is/c++draft/intro.progress#note-1>*: This is intended to allow compiler transformations such as *removal of empty loops, even when termination cannot be proven. <http://eel.is/c++draft/intro.progress#1.sentence-2>* =E2=80=94 *end note*] Alex Data races are specifically because of lack of inter-thread mediation of > access. The language just doesn=E2=80=99t specify that this is possible. > Instruction scheduling compilers do exist, and have for some time for tho= se > languages. I used one on my Amiga with a Motorolla 68040 in the early > 1990=E2=80=99s. That=E2=80=99s a aged and ever-present technology today,= but because of > small block construction of much software, it rarely has an opportunity t= o > fully utilize an extra ALU, but still we have hyper threaded processors > trying to provide that capability. > > > I think the real point you are trying to make here is that insertion of > that qualifying phrase referencing Java makes a /significant/ difference, > whether that's just modulo the general problem or modulo some specific > alternative language (or Java variant) that you want to offer as an > inprovement. Over the years I have written a lot of concurrent and parall= el > code in a lot of different languages and I have to disagree with your > contention on two grounds. > > Non-volatile by default with hoisting being performed makes a significant > difference in how your code is compiled and thus how it is executed and t= he > locality of logic changes that you may not be directly aware of due to th= e > logic of the software as visibly coded. > > > > > 1) I have invariably found that almost all of the difficulty in > concurrent/parallel programming is to do with the concurrency not the > language in which the program is encoded. Fixating on the details of a > language encoding is something beginners do because they don't know how t= o > think about concurrency problems in the abstract, independent of the > language they are using. However, they are seriously missing the point in > being so fixated because the lesson to be learnt from writing a > parallel/concurrent program is not how to encode it in language X but how > any encoding one comes up with embodies a solution that (as is almost > invariably the case) transcends the specifics of language X. > > Yes, but as we all may have learned in college classes, there are well > known algorithms (codified in java.util.concurrent) for managing data > sharing across threads. That=E2=80=99s fine and dandy stuff. However th= e mere > presence of =E2=80=9Cvolatile=E2=80=9D vs =E2=80=9Cnon-volatile=E2=80=9D = references has little to do with > concurrency, but rather asynchronous behaviors, no matter how they are > controlled/initiated. What I mean, is that if you had a boolean in a clas= s, > and provided a JNI method to pass the class reference into some C-languag= e > software that setup a hardware interrupt that would dispatch into that C > code, and the C code then called back through JNI to set the boolean, and > you are on a single core processor, that=E2=80=99s a =E2=80=9Cthread of e= xecution=E2=80=9D and > concurrent behavior, but it=E2=80=99s the stuff that has been done for ag= es, and in > C and C++ there has never been hoisting and the changes that Java=E2=80= =99s > non-volatile default presents, is a completely different behavior. This = is > the surprise. It=E2=80=99s not something explicitly requested, but rathe= r > something implicitly part of the language and it=E2=80=99s completely dif= ferent to > what most people have experienced in other languages. > > Concurrency through the use of well known patterns allows all kinds of > sharing and not-sharing references to be managed. The fact that Java, as= a > concurrent language, chose to not share data by default is the detail. T= he > SPARC hardware memory model was the weakest. It had better throughput > because Sun optimized the JVM to allow that to happen. The JMM largely > reflects the need to have a weak memory model in the processor. The JMM > presses parts of hardware design up into the software systems design wher= e > the concurrency libraries have to manipulate hardware features (happens > before requirements) to make memory references work correctly. > > > 2) Horses for courses is also an edge effect. While some languages do > indeed make management of the concurrency/parallelism easier they often d= o > so at the cost of making other goals much harder. In the worst case a cle= ar > concurrency model can cost al of the performance gains the concurrency > primitives are there to provide. > > This is the reason why the JMM was an important thing to have. It > provides a behavior specification that is independent of the hardware > implementation mostly, but does require some memory consistency constrain= ts > necessary for happens-before to work. > > > For example, I worked on the implementation of a parallel logic languag= e > 30 years ago that was wonderfully transparent as far as modelling > concurrency was concerned, most especially for problems with irregular > parallel decompositons. Unfortunately, achieving high speed-up on > multi-core machines was extremely difficult because the language was /too= / > parallel. Efficient local scheduling of operations with good data localit= y > was extremely hard to achieve. By contrast, parallel Fortran enables very > good localization of computation and data accesses but only for tasks tha= t > decompose (and recompose) regularly. > > One of the interesting things about Fortran is the type of application > that it usually is used for. Lots of math operations do allow instructio= n > scheduling to be taken care of more readily. When I worked at Bell Labs = on > the 5ESS software project, in the early 1990s, their compiler team was > thinking about adding instruction scheduling when they were switching to > use the 68040. I had talked to them about having an Amiga with a 68040 a= nd > a scheduling compiler. They asked me to compile some of the 5ESS code to > see what the compiler could do with it. They were concerned that the > number of =E2=80=9Cif=E2=80=9D statements and other conditional logic aro= und the =E2=80=9Caudit=E2=80=9D > subsystem implementation would not really allow scheduling to be very > effective. It was clear after showing them diffs, that it was hard to > schedule things. But, I did find an assembly statement in the memory > checksumming code where they had used LD R1,0 instead of CLR R1. Making > that change was a huge reduction in CPU =E2=80=9Cbusy=E2=80=9D work alone= . > > I completely understand all the desires around performance not being > impacted. So realistically, removing non-volatile as a default is not an > ideal thing. I=E2=80=99ve been suggesting at least context sensitive war= nings > about the hoisting actually invalidating the software as coded. This is > not a simple deal, thanks for your insights into this and providing some > prodding to think about the bigger picture. > > I am still interested in figuring out whether there is some useful > strategy of inspection that can allow developers to be warned readily of > the misuse of non-volatile values when their intention is volatile/sharin= g > of references. > > Gregg Wonderly > > > > > Your mileage may vary, naturally. > > > > regards, > > > > > > Andrew Dinn > > ----------- > > Red Hat Distinguished Engineer > > Red Hat UK Ltd > > Registered in England and Wales under Company Registration No. 03798903 > > Directors: Michael Cunningham, Michael ("Mike") O'Neill > > > > _______________________________________________ > > Concurrency-interest mailing list > > [email protected] > > http://cs.oswego.edu/mailman/listinfo/concurrency-interest > > --0000000000000fbb1905c7cf759b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr" = class=3D"gmail_attr">On Fri, 23 Jul 2021, 16:24 Gregg Wonderly, <<a href= =3D"mailto:[email protected]">[email protected]</a>> wrote:<br></div><blockquote= class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli= d;padding-left:1ex"><br> <br> > On Jul 23, 2021, at 4:14 AM, Andrew Dinn via Concurrency-interest <= <a href=3D"mailto:[email protected]" target=3D"_blank" rel= =3D"noreferrer">[email protected]</a>> wrote:<br> > <br> > On 23/07/2021 04:36, Gregg Wonderly via Concurrency-interest<br> > <br> >> Truly, it takes pretty extreme expertise and experience to truly<b= r> >> understand how to [use Java to] do concurrent programming.<br> > <br> > Let's just note that if you take out the bracketed phrase that sta= tement still remains true.<br> <br> I added that phrase because my experience with concurrency inside of Java p= rograms is the largest exposure I have.=C2=A0 But that is dated compared to= my use of multi-threaded application in C/C++ that I=E2=80=99ve recently b= een involved in.=C2=A0 In those cases, there is no worry about non-volatile= hoisting doesn=E2=80=99t occur at all.=C2=A0 </blockquote></div></div><div= dir=3D"auto"><br></div><div dir=3D"auto">I am sorry to burst your bubble..= .</div><div dir=3D"auto"><br></div><div dir=3D"auto"><a href=3D"http://eel.= is/c++draft/intro.progress">http://eel.is/c++draft/intro.progress</a><br></= div><div dir=3D"auto"><br></div><div dir=3D"auto">Quote:</div><div dir=3D"a= uto"><div style=3D"background-image:inherit;background-position:inherit;bac= kground-size:inherit;background-repeat:inherit;background-origin:inherit;ba= ckground-clip:inherit;display:inline;font-family:"times new roman"= ;;text-align:justify" dir=3D"auto">The implementation may assume that any t= hread will eventually do one of the following:<ul style=3D"list-style-type:= none;padding-left:9mm;margin-top:0px;margin-bottom:0px"><li style=3D"margin= -top:3pt;margin-bottom:3pt"><div style=3D"background-image:inherit;backgrou= nd-position:inherit;background-size:inherit;background-repeat:inherit;backg= round-origin:inherit;background-clip:inherit"><a href=3D"http://eel.is/c++d= raft/intro.progress#1.1" style=3D"text-decoration-line:none;width:15mm;font= -size:7pt;text-align:right">(1.1)</a></div>terminate,</li><li style=3D"marg= in-top:3pt;margin-bottom:3pt"><div style=3D"background-image:inherit;backgr= ound-position:inherit;background-size:inherit;background-repeat:inherit;bac= kground-origin:inherit;background-clip:inherit"><a href=3D"http://eel.is/c+= +draft/intro.progress#1.2" style=3D"text-decoration-line:none;width:15mm;fo= nt-size:7pt;text-align:right">(1.2)</a></div>make a call to a library I/O f= unction,</li><li style=3D"margin-top:3pt;margin-bottom:3pt"><div style=3D"b= ackground-image:inherit;background-position:inherit;background-size:inherit= ;background-repeat:inherit;background-origin:inherit;background-clip:inheri= t"><a href=3D"http://eel.is/c++draft/intro.progress#1.3" style=3D"text-deco= ration-line:none;width:15mm;font-size:7pt;text-align:right">(1.3)</a></div>= perform an access through a volatile glvalue, or</li><li style=3D"margin-to= p:3pt;margin-bottom:3pt"><div style=3D"background-image:inherit;background-= position:inherit;background-size:inherit;background-repeat:inherit;backgrou= nd-origin:inherit;background-clip:inherit"><a href=3D"http://eel.is/c++draf= t/intro.progress#1.4" style=3D"text-decoration-line:none;width:15mm;font-si= ze:7pt;text-align:right">(1.4)</a></div>perform a synchronization operation= or an atomic operation<a href=3D"http://eel.is/c++draft/intro.progress#1.s= entence-1" style=3D"text-decoration-line:none">.</a></li></ul></div><span s= tyle=3D"font-family:"times new roman";font-size:16px;text-align:j= ustify"></span><div style=3D"background-image:inherit;background-position:i= nherit;background-size:inherit;background-repeat:inherit;background-origin:= inherit;background-clip:inherit;margin-top:5pt;margin-bottom:5pt;font-size:= 11pt;font-family:"times new roman";text-align:justify" dir=3D"aut= o"><div style=3D"background-image:inherit;background-position:inherit;backg= round-size:inherit;background-repeat:inherit;background-origin:inherit;back= ground-clip:inherit;margin-top:3pt;margin-bottom:3pt">[<i>Note=C2=A0<a href= =3D"http://eel.is/c++draft/intro.progress#note-1" style=3D"text-decoration-= line:none">1</a></i>:=C2=A0<div style=3D"background-image:inherit;backgroun= d-position:inherit;background-size:inherit;background-repeat:inherit;backgr= ound-origin:inherit;background-clip:inherit;display:inline">This is intende= d to allow compiler transformations such as <b>removal of empty loops, even= when termination cannot be proven<a href=3D"http://eel.is/c++draft/intro.p= rogress#1.sentence-2" style=3D"text-decoration-line:none">.</a></b></div><b= >=C2=A0</b>=E2=80=94=C2=A0<i>end note</i>]</div></div></div><div dir=3D"aut= o"><br></div><div dir=3D"auto">Alex</div><div dir=3D"auto"><br></div><div d= ir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_quote"><blockqu= ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s= olid;padding-left:1ex">Data races are specifically because of lack of inter= -thread mediation of access.=C2=A0 The language just doesn=E2=80=99t specif= y that this is possible.=C2=A0 Instruction scheduling compilers do exist, a= nd have for some time for those languages.=C2=A0 I used one on my Amiga wit= h a Motorolla 68040 in the early 1990=E2=80=99s.=C2=A0 That=E2=80=99s a age= d and ever-present technology today, but because of small block constructio= n of much software, it rarely has an opportunity to fully utilize an extra = ALU, but still we have hyper threaded processors trying to provide that cap= ability.<br> <br> > I think the real point you are trying to make here is that insertion o= f that qualifying phrase referencing Java makes a /significant/ difference,= whether that's just modulo the general problem or modulo some specific= alternative language (or Java variant) that you want to offer as an inprov= ement. Over the years I have written a lot of concurrent and parallel code = in a lot of different languages and I have to disagree with your contention= on two grounds.<br> <br> Non-volatile by default with hoisting being performed makes a significant d= ifference in how your code is compiled and thus how it is executed and the = locality of logic changes that you may not be directly aware of due to the = logic of the software as visibly coded.<br> <br> > <br> > 1) I have invariably found that almost all of the difficulty in concur= rent/parallel programming is to do with the concurrency not the language in= which the program is encoded. Fixating on the details of a language encodi= ng is something beginners do because they don't know how to think about= concurrency problems in the abstract, independent of the language they are= using. However, they are seriously missing the point in being so fixated b= ecause the lesson to be learnt from writing a parallel/concurrent program i= s not how to encode it in language X but how any encoding one comes up with= embodies a solution that (as is almost invariably the case) transcends the= specifics of language X.<br> <br> Yes, but as we all may have learned in college classes, there are well know= n algorithms (codified in java.util.concurrent) for managing data sharing a= cross threads.=C2=A0 That=E2=80=99s fine and dandy stuff.=C2=A0 However the= mere presence of =E2=80=9Cvolatile=E2=80=9D vs =E2=80=9Cnon-volatile=E2=80= =9D references has little to do with concurrency, but rather asynchronous b= ehaviors, no matter how they are controlled/initiated. What I mean, is that= if you had a boolean in a class, and provided a JNI method to pass the cla= ss reference into some C-language software that setup a hardware interrupt = that would dispatch into that C code, and the C code then called back throu= gh JNI to set the boolean, and you are on a single core processor, that=E2= =80=99s a =E2=80=9Cthread of execution=E2=80=9D and concurrent behavior, bu= t it=E2=80=99s the stuff that has been done for ages, and in C and C++ ther= e has never been hoisting and the changes that Java=E2=80=99s non-volatile = default presents, is a completely different behavior.=C2=A0 This is the sur= prise.=C2=A0 It=E2=80=99s not something explicitly requested, but rather so= mething implicitly part of the language and it=E2=80=99s completely differe= nt to what most people have experienced in other languages.<br> <br> Concurrency through the use of well known patterns allows all kinds of shar= ing and not-sharing references to be managed.=C2=A0 The fact that Java, as = a concurrent language, chose to not share data by default is the detail.=C2= =A0 The SPARC hardware memory model was the weakest.=C2=A0 It had better th= roughput because Sun optimized the JVM to allow that to happen.=C2=A0 The J= MM=C2=A0 largely reflects the need to have a weak memory model in the proce= ssor.=C2=A0 The JMM presses parts of hardware design up into the software s= ystems design where the concurrency libraries have to manipulate hardware f= eatures (happens before requirements) to make memory references work correc= tly.<br> <br> > 2) Horses for courses is also an edge effect. While some languages do = indeed make management of the concurrency/parallelism easier they often do = so at the cost of making other goals much harder. In the worst case a clear= concurrency model can cost al of the performance gains the concurrency pri= mitives are there to provide.<br> <br> This is the reason why the JMM was an important thing to have.=C2=A0 It pro= vides a behavior specification that is independent of the hardware implemen= tation mostly, but does require some memory consistency constraints necessa= ry for happens-before to work.<br> <br> > For example, I worked on the implementation of a parallel logic langua= ge 30 years ago that was wonderfully transparent as far as modelling concur= rency was concerned, most especially for problems with irregular parallel d= ecompositons. Unfortunately, achieving high speed-up on multi-core machines= was extremely difficult because the language was /too/ parallel. Efficient= local scheduling of operations with good data locality was extremely hard = to achieve. By contrast, parallel Fortran enables very good localization of= computation and data accesses but only for tasks that decompose (and recom= pose) regularly.<br> <br> One of the interesting things about Fortran is the type of application that= it usually is used for.=C2=A0 Lots of math operations do allow instruction= scheduling to be taken care of more readily.=C2=A0 When I worked at Bell L= abs on the 5ESS software project, in the early 1990s, their compiler team w= as thinking about adding instruction scheduling when they were switching to= use the 68040.=C2=A0 I had talked to them about having an Amiga with a 680= 40 and a scheduling compiler.=C2=A0 They asked me to compile some of the 5E= SS code to see what the compiler could do with it.=C2=A0 They were concerne= d that the number of =E2=80=9Cif=E2=80=9D statements and other conditional = logic around the =E2=80=9Caudit=E2=80=9D subsystem implementation would not= really allow scheduling to be very effective.=C2=A0 It was clear after sho= wing them diffs, that it was hard to schedule things.=C2=A0 But, I did find= an assembly statement in the memory checksumming code where they had used = LD R1,0 instead of CLR R1.=C2=A0 Making that change was a huge reduction in= CPU =E2=80=9Cbusy=E2=80=9D work alone.<br> <br> I completely understand all the desires around performance not being impact= ed.=C2=A0 So realistically, removing non-volatile as a default is not an id= eal thing.=C2=A0 I=E2=80=99ve been suggesting at least context sensitive wa= rnings about the hoisting actually invalidating the software as coded.=C2= =A0 This is not a simple deal, thanks for your insights into this and provi= ding some prodding to think about the bigger picture.=C2=A0 <br> <br> I am still interested in figuring out whether there is some useful strategy= of inspection that can allow developers to be warned readily of the misuse= of non-volatile values when their intention is volatile/sharing of referen= ces.<br> <br> Gregg Wonderly<br> <br> > <br> > Your mileage may vary, naturally.<br> > <br> > regards,<br> > <br> > <br> > Andrew Dinn<br> > -----------<br> > Red Hat Distinguished Engineer<br> > Red Hat UK Ltd<br> > Registered in England and Wales under Company Registration No. 0379890= 3<br> > Directors: Michael Cunningham, Michael ("Mike") O'Neill<= br> > <br> > _______________________________________________<br> > Concurrency-interest mailing list<br> > <a href=3D"mailto:[email protected]" target=3D"_blank= " rel=3D"noreferrer">[email protected]</a><br> > <a href=3D"http://cs.oswego.edu/mailman/listinfo/concurrency-interest"= rel=3D"noreferrer noreferrer" target=3D"_blank">http://cs.oswego.edu/mailm= an/listinfo/concurrency-interest</a><br> <br> </blockquote></div></div></div> --0000000000000fbb1905c7cf759b-- --===============2280934204692152293== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KQ29uY3VycmVu Y3ktaW50ZXJlc3QgbWFpbGluZyBsaXN0CkNvbmN1cnJlbmN5LWludGVyZXN0QGNzLm9zd2Vnby5l ZHUKaHR0cDovL2NzLm9zd2Vnby5lZHUvbWFpbG1hbi9saXN0aW5mby9jb25jdXJyZW5jeS1pbnRl cmVzdAo= --===============2280934204692152293==--