Re: [go-nuts] Re: What is the correct way to access/modify slice elements concurrently

* burak serdar [191112 12:45]: > Is there a guarantee that the compiler will not reorganize > instructions around an atomic read/write? That is: > > i++ > k:=atomic.AddInt32(,1) > > Is there a guarantee that the compiler won't rewrite this as: > > k:=atomic.AddInt32(,1) > i++ First, from one

Re: [go-nuts] Re: What is the correct way to access/modify slice elements concurrently

* Robert Engels [191112 12:59]: > The bug I referenced discusses the current problem with the MM > specification. You are making assumptions that are not supported by > the current MM, but as the bug points out, that is the current > behavior. I can see that point of view, and I don't think it

Re: [go-nuts] Re: What is the correct way to access/modify slice elements concurrently

iginal Message- >From: Marvin Renich >Sent: Nov 12, 2019 11:20 AM >To: golang-nuts >Subject: Re: [go-nuts] Re: What is the correct way to access/modify slice >elements concurrently > >There are two different viewpoints you can take. Either the Go Memory >Model m

Re: [go-nuts] Re: What is the correct way to access/modify slice elements concurrently

On Tue, Nov 12, 2019 at 10:21 AM Marvin Renich wrote: > > There are two different viewpoints you can take. Either the Go Memory > Model must stand alone, and any concurrency claims made by the language > and standard library must be based on the limited set of operations > defined in the GMM, or

Re: [go-nuts] Re: What is the correct way to access/modify slice elements concurrently

There are two different viewpoints you can take. Either the Go Memory Model must stand alone, and any concurrency claims made by the language and standard library must be based on the limited set of operations defined in the GMM, or the GMM provides the definitions and provides a substantial, but

Re: [go-nuts] Re: What is the correct way to access/modify slice elements concurrently

Again, the issue for the mm is https://github.com/golang/go/issues/5045 but if you read the comments it appears the the de-facto standard is that the atomics do provide “happens before”, but it is not specified that this has to be the case. > On Nov

Re: [go-nuts] Re: What is the correct way to access/modify slice elements concurrently

On Sun, Nov 10, 2019 at 7:08 AM Lars Seipel wrote: > > On Sat, Nov 09, 2019 at 11:00:04AM -0600, Robert Engels wrote: > >No. Because in the absence on a memory barrier the writes may not be flushed > >meaning you cannot reason about any value ever being changed. atomics > >provide the memory

Re: [go-nuts] Re: What is the correct way to access/modify slice elements concurrently

What I meant was that if you read farther down in the synchronization section atomics are not discussed and the issue cited is related. > On Nov 10, 2019, at 8:31 AM, Robert Engels wrote: > > Ignore the first part (error!) but the issue applies in terms of atomic. > >>> On Nov 10, 2019, at

Re: [go-nuts] Re: What is the correct way to access/modify slice elements concurrently

Ignore the first part (error!) but the issue applies in terms of atomic. > On Nov 10, 2019, at 8:08 AM, Lars Seipel wrote: > > On Sat, Nov 09, 2019 at 11:00:04AM -0600, Robert Engels wrote: >> No. Because in the absence on a memory barrier the writes may not be flushed >> meaning you cannot

Re: [go-nuts] Re: What is the correct way to access/modify slice elements concurrently

You are reading the section on “single go routine”. That does not apply here as there are multiple go routines. See https://github.com/golang/go/issues/5045 This is still technical undefined by the memory model. > On Nov 10, 2019, at 8:08 AM, Lars Seipel wrote: > > On Sat, Nov 09, 2019 at

Re: [go-nuts] Re: What is the correct way to access/modify slice elements concurrently

On Sat, Nov 09, 2019 at 11:00:04AM -0600, Robert Engels wrote: No. Because in the absence on a memory barrier the writes may not be flushed meaning you cannot reason about any value ever being changed. atomics provide the memory barrier, but the mm still does not specify a “happens before”

Re: [go-nuts] Re: What is the correct way to access/modify slice elements concurrently

No. Because in the absence on a memory barrier the writes may not be flushed meaning you cannot reason about any value ever being changed. atomics provide the memory barrier, but the mm still does not specify a “happens before” relationship (but without this they are fairly useless). > On

Re: [go-nuts] Re: What is the correct way to access/modify slice elements concurrently

On Fri, Nov 08, 2019 at 06:06:22AM -0600, Robert Engels wrote: I think that is a bit unclear - even if they access different elements, if they ever access the same element even at different times , you need synchronization- it’s not only if the access the same element “concurrently”. No,

Re: [go-nuts] Re: What is the correct way to access/modify slice elements concurrently

I think that is a bit unclear - even if they access different elements, if they ever access the same element even at different times , you need synchronization- it’s not only if the access the same element “concurrently”. >> On Nov 8, 2019, at 2:54 AM, Volker Dobler wrote: >  >> On Friday, 8