Adding [0] to the mix of papers one ought to read. Adrian Colyer had this under his looking glass some months ago: https://blog.acolyer.org/2018/08/09/bounding-data-races-in-space-and-time-part-i/
The work is being done as part of the mutlicore OCaml effort: as part of handling multiple cores, one has to nail a comprehensible memory model so programmers can reason about their programs. Memory models tend to be far more slippery ground than what they have to be. [0] "Bounding Data Races in Space & Time" Dolan, Sivaramakrishnan, Madhavapeddy: http://kcsrk.info/papers/pldi18-memory.pdf On Sun, Feb 3, 2019 at 12:53 AM robert engels <[email protected]> wrote: > 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 <[email protected]> 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, [email protected] 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 [email protected]. > For more options, visit 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 [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- J. -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
