You cannot make that assumption. It's not about what the race detector can detect.
Goroutine one: Writes non-synchronized X Writes atomic Y Writes non-synchronized Z with the value of X+Y Goroutine two Reads atomic Y and sees the new value Can goroutine two now read non-synchronized X and assume it sees the new value written by one? No, it cannot. There is no "happens before" relation connecting the two writes performed by goroutine one. Requirement one does not establish such a relationship. It only establishes that Z will be written with the correct sum of X and Y. There must be *some *sequential order within the context of goroutine one that sees the correct value; the compiler is free to swap the order of the writes X and Y. If X were an atomic, then Requirement two would come into play. But because X and Z are not atomic, they play no role in Requirement two. Note that the description of atomic in the model says that writes to *atomic *values have the property you want. And since there is no before relationship established by any of the following text, this synchronization cannot be relied on. Now you're asking whether the race detector ensures the synchronization property you're suggesting? The race detector doesn't ensure any synchronization properties; it detects bugs. I think it is capable of detecting this one. Thomas On Wed, Sep 14, 2022 at 11:01 PM robert engels <reng...@ix.netcom.com> wrote: > Hi, > > I am working on a new project, and the race detector is reporting a race. > > Essentially, the code is > > var S []int > > several go routines write new S values using a mutex > > go routine Y reads S without grabbing a lock (it reads it initially under > lock) > > The semantics are such that Y can operate successfully with any valid > value of S (e.g. could be stale). (essentially S is used with copy on write > semantics) > > The race detector reports this as a race. > > I could change all reads of Y to use an atomic load, but I don’t think it > should be necessary. > > Is there any way to perform “lazy loads” in Go? > > And a follow-up: > > Is the race detector smart enough so that if a routines write to several > vars (v1…n) and performs an atomic store to X, and another routine > atomically reads X it can also non atomically read v1…n and it will see the > stored values? > > This has been the long standing issue with the Go memory model and > “happens before”… but how does the race detector report this? > > (Some background, the library functions fine under heavy concurrent stress > tests - but the race detector says it is broken). > > > > > -- > 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/8EC74417-C4AD-4490-9231-6E869EE72D93%40ix.netcom.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/CA%2BYjuxtd%2BpaU_BNxXDrMAN9v71r-Qhm9LcXcN2fTtjD_6oWw-Q%40mail.gmail.com.
