The garbage collector ensures that after it has zeroed memory, it does proper synchronization to hand off that memory to an allocator. That allocator (and the goroutine on whose behalf it is working) is then guaranteed to see the zeroed memory. That's how heap memory works. Stack memory is a special case - it is zeroed by the compiler, and there's no synchronization issue because goroutine stacks are not accessible from other goroutines.
On Monday, March 11, 2019 at 4:12:21 AM UTC-7, Shivaram Lingamneni wrote: > > Thanks very much. > > For my own edification, could you give me some pointers (pun not intended) > as to how the current runtime implementation ensures that uninitialized > memory is never visible to any goroutine, even if the only synchronization > used to read it is a sync/atomic primitive? > > On Monday, March 11, 2019 at 1:16:04 AM UTC-4, Ian Lance Taylor wrote: >> >> On Sun, Mar 10, 2019 at 7:54 PM shivaram via golang-nuts >> <golan...@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.
