On Sun, Mar 10, 2019 at 7:54 PM shivaram via golang-nuts <golang-nuts@googlegroups.com> wrote: > > Can users of sync/atomic assume that memory will initially be zeroed? Or is > it necessary for a manual zeroing (using the atomic store operations) to > happen-before any reads? > > Context: https://github.com/golang/go/issues/5045 has the suggestion that > "you shouldn't mix atomic and non-atomic accesses for a given memory word," > and `runtime/HACKING.md` says that zeroing does not always use write barriers: > > https://github.com/golang/go/blob/1c2d4da10f6edf9a83fb0cffaaf9f631f462d26b/src/runtime/HACKING.md#zero-initialization-versus-zeroing > > But the sync.Once implementation doesn't seem to worry about this: > > https://github.com/golang/go/blob/1c2d4da10f6edf9a83fb0cffaaf9f631f462d26b/src/sync/once.go#L41 > > so I'm interested in whether manual zeroing is required, and also in the > reasons why or why not. Thanks for your time.
Variables in Go are always initialized to the zero value of their type. You do not have to zero them yourself. The notes in runtime/HACKING.md only apply to the runtime package, not to general Go code. The meaning of "write barriers" in the note in runtime/HACKING.md doesn't have anything to do with atomic access. Ian -- 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. For more options, visit https://groups.google.com/d/optout.
