Change https://golang.org/cl/381315 mentions this issue: doc: update Go memory model

Change https://golang.org/cl/381316 mentions this issue: runtime, sync, sync/atomic: document happens-before guarantees

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

Based on feedback from ARM, I revised the examples toward the end of the memory model to remove the implication that hoisting reads (provided they don't fault) out of conditionals is always problematic.

Does anyone object to accepting this proposal?

Sorry about leaving a comment on the CL before seeing the comment not to. I continue to believe there are serious problems with the approach, which I will again offer to discuss.

Thanks @hboehm. I will take you up on that offer.

To update the issue here, I had a good discussion with @hboehm.

Hans's primary objection is that the new text claims that Go provides DRF-SC but that the rules given in the current draft are not strong enough to support that claim.

My goal for the current rules is to try to restrict what compilers are allowed to do, to avoid cleverness like reloading a value from memory rather than spilling it to a private location like the stack. In general my goal is to say to users "don't depend on the behavior of racy programs" while at the same time say to compiler writers (in contrast to C/C++) "don't assume programs are race-free / make races worse". That is, we might call this "DRF-SC but avoid catching fire".

Hans believes that for the user part, it should be possible to reduce the C++ DRF-SC model down to something that is reasonable for Go (and much simpler than C++, since we don't have relaxed atomics), and that the compiler writer part can be delivered as informal implementation advice. I am going to look into this approach.

Hans also pointed me at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1217r2.html, in particular the section titled "A new class of out-of-thin-air results", which is certainly worrying. We currently do not allow relaxed atomic loads/stores, but if we did start thinking about those operations, we would need to grapple with what those programs should be allowed to do.

I have updated the text based on a discussion with @hboehm from early April. The main change is to start with a "here are the semantics for race-free programs" section, which explicitly aligns with C, C++, Java, JavaScript, Rust, Swift, and so on. Then the old text limiting the damage possible in racy programs follows as an informal implementation restriction.

In my head, this new text says what I always wanted to say and is a no-op. But formally, it actually says the right things so that race-free programs can be proved to provide sequentially consistent semantics (DRF-SC).

The diff is https://go-review.googlesource.com/c/go/+/381315/5..6.

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

Change https://go.dev/cl/410675 mentions this issue: doc/go_mem: update revision date