Actually, in the comments on that paper it states : A technical note: C++11 essentially prohibits compilers from introducing stores that were not written by the programmer. See 1.10 paragraph 22 of the C++ standard. Previous versions of the standard did permit such an irksome possibility.
I assume Go is the same. > On Feb 2, 2019, at 5:27 PM, robert engels <reng...@ix.netcom.com> wrote: > > I am not sure those critical failures outlined in the paper are possible in > Go, certainly not Java, but I’d like to understand more. > > I don’t think the ‘re-using of the memory’ can happen, since it is a local > variable, and to be seen by another thread it would be captured in a closure > and be protected, and if it was a global variable I think the compiler rules > must prevent a using it for temporary storage, since it could mapped to an IO > location, etc. > > I’ve never seen the re-use as temporary storage - is there some proven > literature on this? > >> On Feb 2, 2019, at 2:35 PM, jake6...@gmail.com <mailto:jake6...@gmail.com> >> wrote: >> >> Always a good read on why that is still a problem: >> Benign Data Races: What Could Possibly Go Wrong? >> <https://software.intel.com/en-us/blogs/2013/01/06/benign-data-races-what-could-possibly-go-wrong> >> It is not specific to go, but mostly applies to any language, and is stuff >> all developers should know. >> >> On Friday, February 1, 2019 at 4:58:11 PM UTC-5, Michael Ellis wrote: >> >> >> On Friday, February 1, 2019 at 11:11:24 AM UTC-5, robert engels wrote: >> >> for { >> if A.a > 100 { >> break >> } >> >> >> Go routine #2 may never see the value of A.a change and so never exit the >> loop. >> >> I'm confused. I can see how that would fail if the test were A.a == 100 >> since Go routine #1 might increment past 100 before #2 , but as written it >> seems wrong only if the application logic depends on Go routine #2 exiting >> the loop as soon as A.a reaches 100 (as opposed to any time afterward.) >> >> What am I missing? >> >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts+unsubscr...@googlegroups.com >> <mailto:golang-nuts+unsubscr...@googlegroups.com>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
