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
On Tue, Mar 20, 2018 at 11:03 AM, shivaram via golang-nuts
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
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
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
On Mon, Mar 19, 2018 at 5:46 AM, shivaram via golang-nuts
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. Bu
On Monday, March 19, 2018 at 9:30:39 AM UTC-7, thepud...@gmail.com wrote:
>
> Hi Ian,
>
> I know you were not giving any type of definitive treatise on how go
> treats atomics across different processors...
>
> but is a related aspect restricting instruction reordering by the compiler
> itself?
Hi Ian,
I know you were not giving any type of definitive treatise on how go treats
atomics across different processors...
but is a related aspect restricting instruction reordering by the compiler
itself?
I don't know what the modern go compiler does at this point, but I think at
least circa
Hi Shivaram,
Regarding the memory model definition and sync/atomic, there is this github
issue that you likely would be interested in:
issue #5045 "doc: define how sync/atomic interacts with memory model"
Including this comment:
=
h
Thanks, this was very helpful. If I understand correctly:
1. These ordering guarantees are part of the Go memory model? I couldn't
find explicit descriptions of them in these pages:
https://golang.org/ref/mem
https://golang.org/pkg/sync/atomic/
2. The property that word-sized values are not sub
On Sun, Mar 18, 2018 at 9:47 PM, shivaram via golang-nuts
wrote:
>
> I noticed that internally, the language implementation seems to rely on the
> atomicity of reads to single-word values:
>
> https://github.com/golang/go/blob/bd859439e72a0c48c64259f7de9f175aae3b9c37/src/runtime/chan.go#L160
In t
I noticed that internally, the language implementation seems to rely on the
atomicity of reads to single-word values:
https://github.com/golang/go/blob/bd859439e72a0c48c64259f7de9f175aae3b9c37/src/runtime/chan.go#L160
As I understand it, this atomicity is provided by the cache coherence
algorit
11 matches
Mail list logo
