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 > . > -- 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/CAEkBMfFn%2BtDgWi_YAMf5gD1Jtc0sBqJKXWidfYQSuTLUd9RUJg%40mail.gmail.com.