If you *want* to read the Memory model that way and write your programs accordingly, you are free to do so. I think you'll find that consistently applying that logic will make it impossible to write correct concurrent programs sharing memory though.
For example, the section about locks <https://go.dev/ref/mem#locks>. In that snippet, `l` and `a` are in different memory locations, so under your reading of the memory model, it would be valid to arbitrarily reorder those operations. However The first call to l.Unlock() (in f) is synchronized before the second call > to l.Lock() (in main) returns, *which is sequenced before the print.* (emphasis mine). It is unambiguously clear that the memory model makes the assumption that within a single goroutine, execution must be consistent with source-order of statements. Every single section demonstrating synchronization primitives contains at least one occurrence of such an assumption. I refuse to believe that you even actually believe your supposed interpretation of the memory model yourself. But if you do, fine. You are unnecessarily hamstringing yourself, in my opinion. But that's your prerogative. On Mon, Aug 15, 2022 at 11:20 AM Changkun Ou <m...@changkun.de> wrote: > > Any other reading, to me, is trying to find an ambiguity for the sole > sake of finding an ambiguity. > > A reader does not have to be motivated to find ambiguity. If the > sentence can be interpreted with different meanings, other readers may > perceive it differently. To me, the first read of this sentence is > perceived to be ambiguous regarding a single location or multiple > locations. The posted example discusses a and b as two memory > locations. > > Atomic operations on a and b are two different statements. It remains > unclear where exactly is the sentence that tries to say this: atomic > operations on different memory locations obey the program statements > order within a goroutine. > On Mon, Aug 15, 2022 at 10:16 AM Axel Wagner > > > > > > <axel.wagner...@googlemail.com> wrote: > > > > On Mon, Aug 15, 2022 at 10:02 AM Changkun Ou <m...@changkun.de> wrote: > >> > >> > The memory operations in each goroutine must correspond to a correct > sequential execution of that goroutine, given the values read from and > written to memory. That execution must be consistent with the sequenced > before relation, defined as the partial order requirements set out by the > Go language specification for Go's control flow constructs as well as the > order of evaluation for expressions. > >> > >> This rule seems a bit unclear in its wording to me. These questions may > occur: > >> 1. What does it mean by "a correct sequential execution"? What defines > >> correct in this case? Is it implied by the variables' written order? > >> > >> 2. Is the rule applicable to multiple variables by written order or > >> only on different variables separately? > > > > > > I think this is trying to pick nits. The rule seems very clear in its > intended outcome: A single goroutine should behave as if executing each > statement sequentially, and obeying the spec about order of evaluation > within a statement. > > > > Any other reading, to me, is trying to find an ambiguity for the sole > sake of finding an ambiguity. Generally, the Go spec and the memory model > as well doesn't try to be tricky just to be tricky. It expects the reader > to apply a certain amount of common sense and biasing themselves towards > the most sensible reading. > > > >> In lines 13 and 14's goroutine, it seems there is no control flow or > >> any given language spec required order of execution. The most relaxing > >> requirement: permit the compiler to switch the statement. > >> > >> > >> On Mon, Aug 15, 2022 at 9:32 AM Axel Wagner > >> <axel.wagner...@googlemail.com> wrote: > >> > > >> > > >> > > >> > On Mon, Aug 15, 2022 at 9:06 AM Changkun Ou <m...@changkun.de> wrote: > >> >> > >> >> I think the new memory model does not guarantee this program always > prints 1: > >> >> > >> >> 1. There is no synchronization guarantee between line 13 and line 14 > >> >> as these atomic operations are manipulated on the different memory > >> >> locations. > >> > > >> > > >> > Yes, there is: > >> >> > >> >> The memory operations in each goroutine must correspond to a correct > sequential execution of that goroutine, given the values read from and > written to memory. That execution must be consistent with the sequenced > before relation, defined as the partial order requirements set out by the > Go language specification for Go's control flow constructs as well as the > order of evaluation for expressions. > >> > > >> > > >> >> 2. It is *not* prohibited for the compiler to switch line 13 and line > >> >> 14 (as I read from section https://go.dev/ref/mem#badcompiler) > because > >> >> of the above reason, and also, there is no order between line 13 and > >> >> line 20. So this is possible: line 14 < line 18 < line 20 < line 13. > >> >> 3. Depending on the memory layout of a and b, if they are on the same > >> >> cache line, then the program will always print 1. > >> >> > >> >> > >> >> On Mon, Aug 15, 2022 at 8:48 AM 'Axel Wagner' via golang-nuts > >> >> <golang-nuts@googlegroups.com> wrote: > >> >> > > >> >> > Why wouldn't it? > >> >> >> > >> >> >> If the effect of an atomic operation A is observed by atomic > operation B, then A is synchronized before B. > >> >> > > >> >> > To me, it seems pretty clear that it will. Line 13 is synchronized > before line 14, which is synchronized before any load observing its effects > (i.e. any execution of line 18 which runs into the branch) - and such a > load is synchronized before the load in line 20. > >> >> > > >> >> > Therefore, the store in Line 13 is synchronized before the load in > line 20. > >> >> > > >> >> > > >> >> > On Mon, Aug 15, 2022 at 8:37 AM tapi...@gmail.com < > tapir....@gmail.com> wrote: > >> >> >> > >> >> >> By the latest version of Go Memory Model article: > https://go.dev/ref/mem, will the following program always print 1? > >> >> >> > >> >> >> https://go.dev/play/p/RICYGip5y8M > >> >> >> > >> >> >> -- > >> >> >> 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. > >> >> >> To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/4d9b8130-d06c-4519-9b99-d161e922d8f6n%40googlegroups.com > . > >> >> > > >> >> > -- > >> >> > 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. > >> >> > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHpwchwjAMtXNtpVmhb42Ncw9ENKhz5xH9Sv1z_-DMrRA%40mail.gmail.com > . > >> > >> > >> > >> -- > >> Changkun Ou (he/him/his) > >> München, Deutschland > >> https://changkun.de/ > > > > -- > Changkun Ou (he/him/his) > München, Deutschland > https://changkun.de/ > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfE6Hah5Lk_pb68P%3Dco%2Bcrh_wFVy8GsK0ya6%3DV1Bxdu87w%40mail.gmail.com.
