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

[Marvin Renich]

* 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 of the issues to which Robert Engels pointed, it appears
that the language designers are in agreement that if atomics are not
covered by the Go Memory Model, they should be.  From this, it seems
safe to me to treat them as if they provide a
does-not-happen-concurrently promise.

>From that (and, independently, from the fact that atomics would
otherwise lose all their documented usefulness) it follows that you have
the same guarantee about reordering that you would have if you replaced
the atomic access with a mutex or channel operation.  Everybody seems to
agree that the compiler can only reorder if such reordering not only
does not affect the behavior of the goroutine being reordered, but also
does not affect the behavior observed by other goroutines _where a
happens-before relationship between those goroutines_ promises such
behavior.

Unfortunately, I cannot find any wording in the GMM that prevents
reordering one goroutine when such reordering breaks a transitive
happens-before relationship with an operation in another goroutine.

The permission to reorder one goroutine is given before the term
"happens before" is defined.  The GMM makes specific guarantees about
the non-transitive happens-before relationships between goroutines, and
gives examples that clearly demonstrate transitive intent, but that
transitive property is never explicitly stated.

In other words, the permission to reorder within one goroutine is never
limited to reordering happens-before operations that do not involve
other goroutines.

I believe this is a much more egregious omission in the GMM than not
mentioning atomics.  It is clearly intended, otherwise the whole GMM is
completely useless.

...Marvin

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/20191113162815.pjh4mrgvaae64xhq%40basil.wdw.

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

[Marvin Renich]

* 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 is incorrect, just
not the only possible POV.

> Btw, there is no such thing as "concurrent access". There is a concept
> of "sharing" and the visibility of operations, and the resulting
> "memory consistency".

I never used the term "concurrent access".  The Go MM never uses the
terms "visibility" or "memory consistency".  Are we talking about the
same document?  I am talking about «https://golang.org/ref/mem».

The MM defines "happens before" and "happens concurrently".  I might
have made a mistake in the terminology that I used, but I do not see it,
and you have not given me enough information to determine what mistake
you believe I have made.

> The current MM is very specific about which operations create a
> "happens before" relationship (an important property of memory
> consistency), atomic operations are not listed.

(same as my first paragraph above)

If the writers of the MM intended it to enumerate all possible language
and standard library features that implement a happens before
relationship, as opposed to defining the terminology and allowing the
language spec and std lib docn to specify that such-and-such a feature
establishes a happens-before relationship, then I agree that something
needs to be added to the MM to cover atomics.

...Marvin

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/20191112192453.x6nuefkdppfshla5%40basil.wdw.

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

[Robert Engels]

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.

Btw, there is no such thing as "concurrent access". There is a concept of 
"sharing" and the visibility of operations, and the resulting "memory 
consistency".

The current MM is very specific about which operations create a "happens 
before" relationship (an important property of memory consistency), atomic 
operations are not listed.





-Original 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 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 not complete, list of operations satisfying that
>definition, and a standard library package (or language feature) may
>claim to satisfy the GMM definitions by some unspecified internal means.
>
>If you accept the second, than I believe the documentation of the
>sync/atomic package is enough to allow atomic operations to be used to
>establish a happens-before relationship.
>
>* burak serdar  [19 21:03]:
>> You cannot define a "happens-before" relationship using only atomics
>  ^ Accepting the atomic documentation, I disagree with this.
>> with the current memory model. The happens-before relationship, the
> ^ Either way, I completely disagree
>  with this.
>> way it is written, relies on one goroutine blocking until the other
>> comes to a point where "things happen" before the block is released.
>> There is no blocking with atomics, hence there is no point in time
>  ^ I (sort of) agree with this, ^ but not this.
>
>Sort of, because any blocking that occurs takes place at the hardware
>level (CPU and memory controller working out any cache and memory bus
>contention).
>
>> where one goroutine can be sure of things happened in the other
>> goroutine.
>> 
>> The only guarantee with atomics is that when one goroutine reads a
>> value, it will read the last written value. There are no guarantees on
>> other values. According to the mm, things that happened before that
>> final write may not be observable to other goroutines.
>
>The memory model is not defined in terms of blocking; in fact the only
>mention of blocking is in the explanatory, non-normative text for
>sync.Once.  Blocking is a consequence of some operations in order to
>obey the memory model; it is not the cause.
>
>The memory model is defined in terms of happens-before relationships,
>and says that certain operations create such a relationship.
>
>My claim is that the GMM gives exactly three mutually exclusive choices:
>
>  Also, if e1 does not happen before e2 and does not happen after e2,
>  then we say that e1 and e2 happen concurrently.
>
>There is no fourth choice, so if e1 and e2 do not happen concurrently,
>then they have one of the happens-before relationships.
>
>Most of the synchronization operations (e.g. channel reads and writes)
>define that a happens-before relationship exists in a specific
>direction.
>
>The atomic package is different in that it specifies that two atomic
>operations to the same memory location do not happen concurrently.  By
>logical inference, rather than explicit statement, there must be a
>happens-before relationship, but the direction of that relationship is
>not specified.  You must use "pure logic" (in the mathematical sense),
>if possible, to determine the direction.
>
>I would be perfectly happy to have the memory model specify:
>
>  If an atomic read r [in one goroutine] can be proven to have observed
>  a specific atomic write w [from another goroutine], than the w
>  happens-before the r.
>
>I like this even better:
>
>  Two atomic operations to the same variable v do not happen
>  concurrently, and thus a happens-before relationship exists between
>  them in an unspecified direction.  Sometimes logic may be used to
>  prove the direction of the relationship.
>
>If you adhere to the first viewpoint at the top of this message, than I
>would say something like the above would be a mandatory addition to the
>GMM document.  However, I am perfectly happy with the viewpoint that the
>GMM provides the definitions, and the list of operations satisfying

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

[burak serdar]

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 the GMM provides the definitions and provides a
> substantial, but not complete, list of operations satisfying that
> definition, and a standard library package (or language feature) may
> claim to satisfy the GMM definitions by some unspecified internal means.
>
> If you accept the second, than I believe the documentation of the
> sync/atomic package is enough to allow atomic operations to be used to
> establish a happens-before relationship.

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++

>
> * burak serdar  [19 21:03]:
> > You cannot define a "happens-before" relationship using only atomics
>   ^ Accepting the atomic documentation, I disagree with this.
> > with the current memory model. The happens-before relationship, the
>  ^ Either way, I completely disagree
>with this.
> > way it is written, relies on one goroutine blocking until the other
> > comes to a point where "things happen" before the block is released.
> > There is no blocking with atomics, hence there is no point in time
>   ^ I (sort of) agree with this, ^ but not this.
>
> Sort of, because any blocking that occurs takes place at the hardware
> level (CPU and memory controller working out any cache and memory bus
> contention).
>
> > where one goroutine can be sure of things happened in the other
> > goroutine.
> >
> > The only guarantee with atomics is that when one goroutine reads a
> > value, it will read the last written value. There are no guarantees on
> > other values. According to the mm, things that happened before that
> > final write may not be observable to other goroutines.
>
> The memory model is not defined in terms of blocking; in fact the only
> mention of blocking is in the explanatory, non-normative text for
> sync.Once.  Blocking is a consequence of some operations in order to
> obey the memory model; it is not the cause.
>
> The memory model is defined in terms of happens-before relationships,
> and says that certain operations create such a relationship.
>
> My claim is that the GMM gives exactly three mutually exclusive choices:
>
>   Also, if e1 does not happen before e2 and does not happen after e2,
>   then we say that e1 and e2 happen concurrently.
>
> There is no fourth choice, so if e1 and e2 do not happen concurrently,
> then they have one of the happens-before relationships.
>
> Most of the synchronization operations (e.g. channel reads and writes)
> define that a happens-before relationship exists in a specific
> direction.
>
> The atomic package is different in that it specifies that two atomic
> operations to the same memory location do not happen concurrently.  By
> logical inference, rather than explicit statement, there must be a
> happens-before relationship, but the direction of that relationship is
> not specified.  You must use "pure logic" (in the mathematical sense),
> if possible, to determine the direction.
>
> I would be perfectly happy to have the memory model specify:
>
>   If an atomic read r [in one goroutine] can be proven to have observed
>   a specific atomic write w [from another goroutine], than the w
>   happens-before the r.
>
> I like this even better:
>
>   Two atomic operations to the same variable v do not happen
>   concurrently, and thus a happens-before relationship exists between
>   them in an unspecified direction.  Sometimes logic may be used to
>   prove the direction of the relationship.
>
> If you adhere to the first viewpoint at the top of this message, than I
> would say something like the above would be a mandatory addition to the
> GMM document.  However, I am perfectly happy with the viewpoint that the
> GMM provides the definitions, and the list of operations satisfying
> those definitions can be specified in the Language Specification and the
> standard library documentation.
>
> ...Marvin
>
> --
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/20191112172034.nkhmoaqjjrawc7wx%40basil.wdw.

-- 
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.
To view this discussion on the web 

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

[Marvin Renich]

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 not complete, list of operations satisfying that
definition, and a standard library package (or language feature) may
claim to satisfy the GMM definitions by some unspecified internal means.

If you accept the second, than I believe the documentation of the
sync/atomic package is enough to allow atomic operations to be used to
establish a happens-before relationship.

* burak serdar  [19 21:03]:
> You cannot define a "happens-before" relationship using only atomics
  ^ Accepting the atomic documentation, I disagree with this.
> with the current memory model. The happens-before relationship, the
 ^ Either way, I completely disagree
   with this.
> way it is written, relies on one goroutine blocking until the other
> comes to a point where "things happen" before the block is released.
> There is no blocking with atomics, hence there is no point in time
  ^ I (sort of) agree with this, ^ but not this.

Sort of, because any blocking that occurs takes place at the hardware
level (CPU and memory controller working out any cache and memory bus
contention).

> where one goroutine can be sure of things happened in the other
> goroutine.
> 
> The only guarantee with atomics is that when one goroutine reads a
> value, it will read the last written value. There are no guarantees on
> other values. According to the mm, things that happened before that
> final write may not be observable to other goroutines.

The memory model is not defined in terms of blocking; in fact the only
mention of blocking is in the explanatory, non-normative text for
sync.Once.  Blocking is a consequence of some operations in order to
obey the memory model; it is not the cause.

The memory model is defined in terms of happens-before relationships,
and says that certain operations create such a relationship.

My claim is that the GMM gives exactly three mutually exclusive choices:

  Also, if e1 does not happen before e2 and does not happen after e2,
  then we say that e1 and e2 happen concurrently.

There is no fourth choice, so if e1 and e2 do not happen concurrently,
then they have one of the happens-before relationships.

Most of the synchronization operations (e.g. channel reads and writes)
define that a happens-before relationship exists in a specific
direction.

The atomic package is different in that it specifies that two atomic
operations to the same memory location do not happen concurrently.  By
logical inference, rather than explicit statement, there must be a
happens-before relationship, but the direction of that relationship is
not specified.  You must use "pure logic" (in the mathematical sense),
if possible, to determine the direction.

I would be perfectly happy to have the memory model specify:

  If an atomic read r [in one goroutine] can be proven to have observed
  a specific atomic write w [from another goroutine], than the w
  happens-before the r.

I like this even better:

  Two atomic operations to the same variable v do not happen
  concurrently, and thus a happens-before relationship exists between
  them in an unspecified direction.  Sometimes logic may be used to
  prove the direction of the relationship.

If you adhere to the first viewpoint at the top of this message, than I
would say something like the above would be a mandatory addition to the
GMM document.  However, I am perfectly happy with the viewpoint that the
GMM provides the definitions, and the list of operations satisfying
those definitions can be specified in the Language Specification and the
standard library documentation.

...Marvin

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/20191112172034.nkhmoaqjjrawc7wx%40basil.wdw.

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

[robert engels]

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 11, 2019, at 8:02 PM, burak serdar  wrote:
> 
> 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 barrier, but the mm still does not specify a 
>>> “happens before” relationship (but without this they are fairly useless).
>> 
>> Visibility is implied by the definition of "no concurrent access".
>> 
>> This case is fully handled by the current memory model:
> 
> 
> You cannot define a "happens-before" relationship using only atomics
> with the current memory model. The happens-before relationship, the
> way it is written, relies on one goroutine blocking until the other
> comes to a point where "things happen" before the block is released.
> There is no blocking with atomics, hence there is no point in time
> where one goroutine can be sure of things happened in the other
> goroutine.
> 
> The only guarantee with atomics is that when one goroutine reads a
> value, it will read the last written value. There are no guarantees on
> other values. According to the mm, things that happened before that
> final write may not be observable to other goroutines.
> 
> 
> 
>> 
>>> Also, if e1 does not happen before e2 and does not happen after e2, then
>>> we say that e1 and e2 happen concurrently.
>> 
>> […]
>> 
>>> That is, r is guaranteed to observe w if both of the following hold:
>>> 
>>> 1. w happens before r.
>>> 2. Any other write to the shared variable v either happens before w or 
>>> after r.
>> [https://golang.org/ref/mem#tmp_2]
>> 
>> --
>> 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.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/20191110140757.GB83577%40horsthansen.slrz.net.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/439AC344-C698-4281-87BB-8C33839FB6C5%40ix.netcom.com.

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

[burak serdar]

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 barrier, but the mm still does not specify a “happens 
> >before” relationship (but without this they are fairly useless).
>
> Visibility is implied by the definition of "no concurrent access".
>
> This case is fully handled by the current memory model:


You cannot define a "happens-before" relationship using only atomics
with the current memory model. The happens-before relationship, the
way it is written, relies on one goroutine blocking until the other
comes to a point where "things happen" before the block is released.
There is no blocking with atomics, hence there is no point in time
where one goroutine can be sure of things happened in the other
goroutine.

The only guarantee with atomics is that when one goroutine reads a
value, it will read the last written value. There are no guarantees on
other values. According to the mm, things that happened before that
final write may not be observable to other goroutines.



>
> > Also, if e1 does not happen before e2 and does not happen after e2, then
> > we say that e1 and e2 happen concurrently.
>
> […]
>
> > That is, r is guaranteed to observe w if both of the following hold:
> >
> >  1. w happens before r.
> >  2. Any other write to the shared variable v either happens before w or 
> > after r.
> [https://golang.org/ref/mem#tmp_2]
>
> --
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/20191110140757.GB83577%40horsthansen.slrz.net.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAMV2Rqrs2TQWZhDt2uece7OSr8k9ShrT_Anzv4Wp-mLTbFwh%2Bw%40mail.gmail.com.

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

[Robert Engels]

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 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 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).
>> 
>> Visibility is implied by the definition of "no concurrent access".
>> 
>> This case is fully handled by the current memory model:
>> 
>>> Also, if e1 does not happen before e2 and does not happen after e2, then we 
>>> say that e1 and e2 happen concurrently.
>> 
>> […]
>> 
>>> That is, r is guaranteed to observe w if both of the following hold:
>>> 1. w happens before r.
>>> 2. Any other write to the shared variable v either happens before w or 
>>> after r.
>> [https://golang.org/ref/mem#tmp_2]
>> 
>> -- 
>> 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.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/20191110140757.GB83577%40horsthansen.slrz.net.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/B86A9AAA-745B-42B1-88F6-74E656B544CE%40ix.netcom.com.

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

[Robert Engels]

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 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).
> 
> Visibility is implied by the definition of "no concurrent access".
> 
> This case is fully handled by the current memory model:
> 
>> Also, if e1 does not happen before e2 and does not happen after e2, then we 
>> say that e1 and e2 happen concurrently.
> 
> […]
> 
>> That is, r is guaranteed to observe w if both of the following hold:
>> 1. w happens before r.
>> 2. Any other write to the shared variable v either happens before w or after 
>> r.
> [https://golang.org/ref/mem#tmp_2]
> 
> -- 
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/20191110140757.GB83577%40horsthansen.slrz.net.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/E349892F-5D9E-4E12-B5ED-3E7C18C3E928%40ix.netcom.com.

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

[Robert Engels]

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 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” relationship (but without this they are fairly useless).
> 
> Visibility is implied by the definition of "no concurrent access".
> 
> This case is fully handled by the current memory model:
> 
>> Also, if e1 does not happen before e2 and does not happen after e2, then we 
>> say that e1 and e2 happen concurrently.
> 
> […]
> 
>> That is, r is guaranteed to observe w if both of the following hold:
>> 1. w happens before r.
>> 2. Any other write to the shared variable v either happens before w or after 
>> r.
> [https://golang.org/ref/mem#tmp_2]
> 
> -- 
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/20191110140757.GB83577%40horsthansen.slrz.net.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/165388B3-18A4-425D-8F16-B640B1894F3D%40ix.netcom.com.

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

[Lars Seipel]

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” 
relationship (but without this they are fairly useless).


Visibility is implied by the definition of "no concurrent access".

This case is fully handled by the current memory model:

Also, if e1 does not happen before e2 and does not happen after e2, then 
we say that e1 and e2 happen concurrently.


[…]


That is, r is guaranteed to observe w if both of the following hold:

 1. w happens before r.
 2. Any other write to the shared variable v either happens before w or after r.

[https://golang.org/ref/mem#tmp_2]

--
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/20191110140757.GB83577%40horsthansen.slrz.net.

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

[Robert Engels]

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 Nov 9, 2019, at 9:51 AM, Lars Seipel  wrote:
> 
> 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, that seems wrong. If, for any two distinct accesses A and B, either A 
> happens before B or B happens before A (i.e. there is no concurrent access), 
> what would you need additional synchronization for? Access is already 
> serialized.
> 
> -ls

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/22528E12-CFE8-450E-876E-DB19C9B975C3%40ix.netcom.com.

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

[Lars Seipel]

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, that seems wrong. If, for any two distinct accesses A and B, either 
A happens before B or B happens before A (i.e. there is no concurrent 
access), what would you need additional synchronization for? Access is 
already serialized.


-ls

--
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/20191109155103.GA83577%40horsthansen.slrz.net.

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

[Robert Engels]

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 November 2019 05:47:03 UTC+1, Kasun Vithanage wrote:
>> What is the best approach?
> 
> There is no single "best approach".
> 
> If two goroutines A and B access two different indices iA and iB you
> do not need any synchronisation between them. If iA==iB you need
> to protect reads from concurrent writes.
> 
> If you have far more reads than writes: Use a RWMutex, otherwise
> a Mutex probably is fine. The trick here: Experiment and measure.
> 
> You can synchronise on the Bar-level or on the level of individual Foos.
> Or you can group lets say N Foos together and synchronise on the
> level of these groups. The trick here: Experiment and measure.
> 
> So it boils down to: What is your access pattern? Make several
> experiments which simulate this pattern and measure. Then decide
> on "the best".
> 
> V.
>  
> -- 
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/e8fd2954-6b46-4337-8564-16e3f771098d%40googlegroups.com.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/F3D828C7-8DC4-4887-8BA1-9B8115E7690A%40ix.netcom.com.

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

[Volker Dobler]

On Friday, 8 November 2019 05:47:03 UTC+1, Kasun Vithanage wrote:
>
> What is the best approach?
>

There is no single "best approach".

If two goroutines A and B access two different indices iA and iB you
do not need any synchronisation between them. If iA==iB you need
to protect reads from concurrent writes.

If you have far more reads than writes: Use a RWMutex, otherwise
a Mutex probably is fine. The trick here: Experiment and measure.

You can synchronise on the Bar-level or on the level of individual Foos.
Or you can group lets say N Foos together and synchronise on the
level of these groups. The trick here: Experiment and measure.

So it boils down to: What is your access pattern? Make several
experiments which simulate this pattern and measure. Then decide
on "the best".

V.
 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e8fd2954-6b46-4337-8564-16e3f771098d%40googlegroups.com.