On Thu, Sep 15, 2022 at 8:03 AM 'Thomas Bushnell BSG' via golang-nuts < golang-nuts@googlegroups.com> wrote:
> 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 > The way I read the Go memory model, if Goroutine two sees the new value of Y, non-synchronizes writes to X by Goroutine 2 happened before Y, and thus, anything that happens after Y. This is based on: "If a synchronizing read-like memory operation r observes a synchronizing write-like memory operation w (that is, if W(r) = w), then w is synchronized before r." And: "The happens before relation is defined as the transitive closure of the union of the sequenced before and synchronized before relations." Because: * The writes to non-synchronized X are sequenced before the atomic write to Y * The atomic read Y happened after atomic write to Y if it sees the new value * non-synchronized reads from X happen after that So that should not be a race. Am I reading this correctly? > > 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 > <https://groups.google.com/d/msgid/golang-nuts/CA%2BYjuxtd%2BpaU_BNxXDrMAN9v71r-Qhm9LcXcN2fTtjD_6oWw-Q%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/CAMV2Rqr4vggPOWjiQg6qN0tJjhhXncKHLMCDwkqZTHBJJ7%3Dmug%40mail.gmail.com.
