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.
