At risk of causing more confusion, here's my understanding of the situation after observing a lot of discussion about the memory model over the years.
There are at least two different things one might mean when referring to the Go memory model: 1. The written contract as specified by the language spec, the sync and sync/atomic documentation, and https://golang.org/ref/mem. 2. The much stricter, unwritten (AFAIK), and possibly fuzzier contract which the Go team tries to implement, which holds that races which violate (1) shouldn't be interpreted as license for the compiler/runtime to do arbitrarily bad things, as has been the case in C/C++-world. For the most part the race detector implements checks for things that violate (1) plus some reasonable assumptions about things which ought to be part of (1) but haven't been written down formally yet (such as https://github.com/golang/go/issues/5045). When Ian wrote "My impression is that that is guaranteed by the Go memory model." I think he was referring to (2). It's certainly intentional that data races on even word-sized values on amd64 are considered faulty according to (1) and the race detector. On Tue, Mar 20, 2018 at 11:03 AM, shivaram via golang-nuts <golang-nuts@googlegroups.com> wrote: > The race detector in v1.10 considers unsynchronized reads and writes on the > `int` and `bool` types to be races: > > https://gist.github.com/slingamn/886ebeba32f04294028cf0a60a8cc8c0 > > Are these instances of the race detector being stricter than the memory > model? > > On Monday, March 19, 2018 at 8:59:15 PM UTC-4, Ian Lance Taylor wrote: >> >> On Mon, Mar 19, 2018 at 5:46 AM, shivaram via golang-nuts >> <golan...@googlegroups.com> wrote: >> > >> > 2. The property that word-sized values are not subject to >> > interleaving/tearing is an implementation detail, rather than a >> > guarantee of >> > the Go memory model? >> >> My impression is that that is guaranteed by the Go memory model. But >> the runtime package is in some sense not subject to the Go memory >> model, since it is responsible for implementing the Go memory model. >> >> 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. -- 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.
