I think it needs to see the updated X - which agrees with burak. Reading Z is race.
> On Sep 15, 2022, at 9:24 AM, burak serdar <bser...@computer.org> wrote: > > > >> 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. > > -- > 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. -- 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/C508E399-78B0-4060-B52C-519D9F52E3FC%40ix.netcom.com.
