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 <https://go.dev/ref/spec#Order_of_evaluation>. 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/ > -- 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/CAEkBMfH95UGX69mZreaT7AUhh0HbkJajJBTkyuVaUdR7y37CqA%40mail.gmail.com.
