Ignore the first part - got bit by the ol' append() and that slices are a struct not a pointer - so they can’t be atomically updated (need to use atomic.Value I guess) - so it was simpler to wrap in Lock/Unlock when accessing the slice and ensure a new slice was used during assignment.
The follow-up question still stands. > On Sep 14, 2022, at 10: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/6F4C1D2C-5549-43FB-B8A2-086F654D9A09%40ix.netcom.com.
