> I believe your example is basically equivalent to the ones in https://go.dev/ref/mem#badsync which also contains an explanation of how the memory model implies this
@Wagner Thanks for your opinion, I think so too. I was not confident that my example is equivalent to https://go.dev/ref/mem#badsync, since my example reads from the same variable. > Programs that modify data being simultaneously accessed by multiple goroutines must serialize such access. @peterGo I know that my example has data races. But the Go Memory Model guarantees a limited number of outcomes for programs with races(unless runtime reports the race and terminates). My question is about the limited outcomes. 2022年12月2日(金) 22:02 Axel Wagner <axel.wagner...@googlemail.com>: > I believe your example is basically equivalent to the ones in > https://go.dev/ref/mem#badsync which also contains an explanation of how > the memory model implies this (or rather, how it does not imply the > opposite). > > On Fri, Dec 2, 2022, 13:11 のびしー <nobishi...@gmail.com> wrote: > >> Hello, I have another question regarding the Go Memory Model. >> >> (1) Can this program print "10", according to the Memory Model? >> (2) If that is forbidden, which part of the Go Memory Model excludes such >> behavior? >> >> https://go.dev/play/p/Fn5I0fjSiKj >> >> ```go >> package main >> >> var x int = 0 >> >> func main() { >> go func() { >> x = 1 >> }() >> print(x) // first read: 1 >> print(x) // second read: 0 >> } >> ``` >> >> I draw a picture of the happens-before relation of this program here: >> >> >> https://gist.github.com/nobishino/8150346c30101e2ca409ed83c6c25add?permalink_comment_id=4388680#gistcomment-4388680 >> >> I think the answer to (1) is yes. >> Both reads are concurrent with x = 1, so each read can observe both x = 0 >> and x = 1. >> And there is no constraint between the results of the first read and the >> second read. >> So the second read can observe x = 0 even if the first read observes x = >> 0. >> >> But I'm not very sure. Is this understanding correct? >> >> -- >> 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/CAGoET5HyPxEhBETGWNPuYpDgXbm0JM3jeaKFdoQdtc5eGUR0Uw%40mail.gmail.com >> <https://groups.google.com/d/msgid/golang-nuts/CAGoET5HyPxEhBETGWNPuYpDgXbm0JM3jeaKFdoQdtc5eGUR0Uw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- 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/CAGoET5Fk6Wwd7JOJOY%3DJVix9NymsP3yJ_P%2BaDPgtPTorL-X_Wg%40mail.gmail.com.
