I saw John Regehr's definitions [1] of "data race" versus "race condition", which were helpful. If I've understood correctly:
a. These examples have "data races", as defined by the race detector documentation [2]: "a data race occurs when two goroutines access the same variable concurrently and at least one of the accesses is a write." b. but they don't have "race conditions", inasmuch as (according to a version of the Go memory model that includes the non-interleaving guarantee) the semantics are the same as those of a program where the same reads and writes are performed with the sync.atomic primitives, or under a mutex. [1] https://blog.regehr.org/archives/490 [2] https://golang.org/doc/articles/race_detector.html On Tuesday, March 20, 2018 at 3:19:48 PM UTC-4, Ian Lance Taylor wrote: > > On Tue, Mar 20, 2018 at 11:03 AM, shivaram via golang-nuts > <golan...@googlegroups.com <javascript:>> 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? > > No, that example is a race. In what way is it not a race? > > I think that the Go memory model guarantees that a read will see > either one write or the other, not an interleaving of the writes. But > that doesn't mean that it's not a race. The memory model explains > what a race is, and it pretty clearly includes cases like your > example. > > Ian > > > > 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.
