Re: [go-nuts] lock for assigning to different elements of an array

Adding [0] to the mix of papers one ought to read. Adrian Colyer had this under his looking glass some months ago: https://blog.acolyer.org/2018/08/09/bounding-data-races-in-space-and-time-part-i/ The work is being done as part of the mutlicore OCaml effort: as part of handling multiple cores,

Re: [go-nuts] lock for assigning to different elements of an array

Actually, in the comments on that paper it states : A technical note: C++11 essentially prohibits compilers from introducing stores that were not written by the programmer. See 1.10 paragraph 22 of the C++ standard. Previous versions of the standard did permit such an irksome possibility. I

Re: [go-nuts] lock for assigning to different elements of an array

I am not sure those critical failures outlined in the paper are possible in Go, certainly not Java, but I’d like to understand more. I don’t think the ‘re-using of the memory’ can happen, since it is a local variable, and to be seen by another thread it would be captured in a closure and be

Re: [go-nuts] lock for assigning to different elements of an array

On Saturday, February 2, 2019 at 3:36:17 PM UTC-5, Jake Montgomery wrote: > > Always a good read on why that is still a problem: > Benign Data Races: What Could Possibly Go Wrong? > > It is not

Re: [go-nuts] lock for assigning to different elements of an array

On Friday, February 1, 2019 at 5:38:49 PM UTC-5, robert engels wrote: > > The pseudo code for the correct code would look like: > Robert, thanks very much for the clear explanation and correct example. I'd totally forgotten that Go is threaded underneath the hood and was thinking only in

Re: [go-nuts] lock for assigning to different elements of an array

Always a good read on why that is still a problem: Benign Data Races: What Could Possibly Go Wrong? It is not specific to go, but mostly applies to any language, and is stuff all developers should

Re: [go-nuts] lock for assigning to different elements of an array

The pseudo code for the correct code would look like: struct { a int } go routine #1: for { atomic.Store(,A.a + 1) // this is ok since only a single writer or even better the following: atomic.Increment(,1) } go routine #2 : for { if atomic.Load() > 100 { break } >

Re: [go-nuts] lock for assigning to different elements of an array

Making things worse, Go’s "memory model" is very loosely defined, so even the correct use of atomics may not work on all platforms. You can read up on “happens before” which is the key aspect. > On Feb 1, 2019, at 4:32 PM, robert engels wrote: > > Because there is no write barrier - so the

Re: [go-nuts] lock for assigning to different elements of an array

Because there is no write barrier - so the changes that Go routine #1 makes may all be local (in a register), and never flushed to memory. Go routine #2 is also free to keep using the last read value from the cache since there is nothing that would force the cache to be refreshed. The is an

Re: [go-nuts] lock for assigning to different elements of an array

When machines (compilers or processors) are allowed to optimise things, reality gets weird. The compiler may elide the check because it is not conformant with the spec via the memory model, or value A.a may be in a local CPU cache and so never be altered as far as the core is concerned. On Fri,

Re: [go-nuts] lock for assigning to different elements of an array

On Friday, February 1, 2019 at 11:11:24 AM UTC-5, robert engels wrote: > > > for { >if A.a > 100 { > break > } > > > Go routine #2 may never see the value of A.a change and so never exit the > loop. > I'm confused. I can see how that would fail if the test were A.a == 100 since Go

Re: [go-nuts] lock for assigning to different elements of an array

It is not the writing - it is the reading, and what is “visible”. The point was that you need to use atomics if you write to ANY structure field and read that field from another Go routine - barring any other synchronization method (WaitGroup, Lock, etc.) The secondary point is, if you use

Re: [go-nuts] lock for assigning to different elements of an array

On Fri, 1 Feb 2019, 4:11 pm robert engels There is nothing reading the value in that code - so that would always be > safe… > > Here is a more common example that many people get wrong (pseudo code) > > struct { >a int > } > > go routine #1: > > for { >A.a = A.a + 1 > } > > go routine #2

Re: [go-nuts] lock for assigning to different elements of an array

There is nothing reading the value in that code - so that would always be safe… Here is a more common example that many people get wrong (pseudo code) struct { a int } go routine #1: for { A.a = A.a + 1 } go routine #2 : for { if A.a > 100 { break } Go routine #2 may never

Re: [go-nuts] lock for assigning to different elements of an array

On Fri, 1 Feb 2019, 3:18 pm Robert Engels To clarify though, you still need to use atomics. > Really? For writing to different fields in a struct? So the following code is not generally safe? (I often rely on this kind of code being safe so if it isn't, I need to know!). type S struct { a A

Re: [go-nuts] lock for assigning to different elements of an array

To clarify though, you still need to use atomics. > On Feb 1, 2019, at 8:52 AM, roger peppe wrote: > > > >> On Thu, 3 Aug 2017, 8:45 am Dave Cheney > >> >>> On Thu, 3 Aug 2017, 17:39 Dave Cheney wrote: >>> Your first program has a data race, well it has two races, the first is a >>> data

Re: [go-nuts] lock for assigning to different elements of an array

On Thu, 3 Aug 2017, 8:45 am Dave Cheney > > On Thu, 3 Aug 2017, 17:39 Dave Cheney wrote: > >> Your first program has a data race, well it has two races, the first is a >> data race between the goroutines writing to the slice and the println which >> will read the contents of the slice. That is,

Re: [go-nuts] lock for assigning to different elements of an array

On Fri, 1 Feb 2019, 2:56 pm Robert Engels That is safe to do. I am referring to the performance hit due to false > sharing for fields that are updated independently by being close together > in memory. > I'm sorry if my sloppy "I'm replying on my phone" message quoting made it unclear, but I was

Re: [go-nuts] lock for assigning to different elements of an array

That is not required for simple counters that are incremented by multiple and read by one. Atomics suffice. > On Feb 1, 2019, at 8:24 AM, Jesper Louis Andersen > wrote: > >> On Thu, Aug 3, 2017 at 9:21 AM Henrik Johansson wrote: > >> I think I am mostly after a mental pattern to easily

Re: [go-nuts] lock for assigning to different elements of an array

That is safe to do. I am referring to the performance hit due to false sharing for fields that are updated independently by being close together in memory. > On Feb 1, 2019, at 8:52 AM, roger peppe wrote: > > > >> On Thu, 3 Aug 2017, 8:45 am Dave Cheney > >> >>> On Thu, 3 Aug 2017, 17:39

Re: [go-nuts] lock for assigning to different elements of an array

On Thu, Aug 3, 2017 at 9:21 AM Henrik Johansson wrote: > I think I am mostly after a mental pattern to easily recognise when > synchronizations are needed. > Assume every write to memory takes 10 seconds and is asynchronous, except that you have Read-Your-Own writes in a goroutine. You can

Re: [go-nuts] lock for assigning to different elements of an array

You can prevent the false sharing by using additional memory and putting gaps between the elements. You need to use atomics even if only written by a single if there is a collating routine that is reading the values. > On Feb 1, 2019, at 6:37 AM, Marvin Renich wrote: > > *

Re: [go-nuts] lock for assigning to different elements of an array

* johnmr...@gmail.com [190131 23:50]: > > Writing to adjacent memory locations [i.e. different array elements, from > > different goroutines] will cause false sharing between CPU caches. This is > > a performance, not a correctness issue. > > I'm looking to make an array of thread-safe

Re: [go-nuts] lock for assigning to different elements of an array

> > Writing to adjacent memory locations [i.e. different array elements, from > different goroutines] will cause false sharing between CPU caches. This is > a performance, not a correctness issue. > I'm looking to make an array of thread-safe counters - each counting a different thing. I

Re: [go-nuts] lock for assigning to different elements of an array

It does help, thank you Konstantin. tors 3 aug. 2017 kl 10:25 skrev Konstantin Khomoutov : > On Thu, Aug 03, 2017 at 07:21:24AM +, Henrik Johansson wrote: > > [...] > > It gets hypothetical pretty quick and usually when this happens I make > sure > > to create a new

Re: [go-nuts] lock for assigning to different elements of an array

On Thu, Aug 03, 2017 at 07:21:24AM +, Henrik Johansson wrote: [...] > It gets hypothetical pretty quick and usually when this happens I make sure > to create a new array/slice/whatever and then atomically swap it before > some other goroutine uses it but I generally avoid indexing assignment

Re: [go-nuts] lock for assigning to different elements of an array

Excellent, thank you Dave! tors 3 aug. 2017 kl 09:45 skrev Dave Cheney : > > > On Thu, 3 Aug 2017, 17:39 Dave Cheney wrote: > >> Your first program has a data race, well it has two races, the first is a >> data race between the goroutines writing to the slice

Re: [go-nuts] lock for assigning to different elements of an array

On Thu, 3 Aug 2017, 17:39 Dave Cheney wrote: > Your first program has a data race, well it has two races, the first is a > data race between the goroutines writing to the slice and the println which > will read the contents of the slice. That is, if those writing goroutines >

Re: [go-nuts] lock for assigning to different elements of an array

Your first program has a data race, well it has two races, the first is a data race between the goroutines writing to the slice and the println which will read the contents of the slice. That is, if those writing goroutines get a chance to run before main exits. The second program doesn't have a

Re: [go-nuts] lock for assigning to different elements of an array

But isn't this what is happening in the example? Or is write-only not sharing? On Thu, 3 Aug 2017, 09:23 Dave Cheney, wrote: > IMO you need a lock whenever you are sharing a value between goroutines by > storing it in memory. > > On Thu, 3 Aug 2017, 17:21 Henrik Johansson

Re: [go-nuts] lock for assigning to different elements of an array

I think I am mostly after a mental pattern to easily recognise when synchronizations are needed. I am decently good at this but I tend to be very conservative and use locks and atomics perhaps when they are not needed. But here we have several goroutines all taking part in the initialisation

Re: [go-nuts] lock for assigning to different elements of an array

IMO you need a lock whenever you are sharing a value between goroutines by storing it in memory. On Thu, 3 Aug 2017, 17:21 Henrik Johansson wrote: > I think I am mostly after a mental pattern to easily recognise when > synchronizations are needed. > > I am decently good at

Re: [go-nuts] lock for assigning to different elements of an array

I'm not really sure what you are asking. I think your second paragraph got eaten by autocorrect at the critical point. Could try maybe asking your question in a different way? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from

Re: [go-nuts] lock for assigning to different elements of an array

How should I know when it is safe to omit using locks? What I have drilled into my head is "yes you not only need a lock but every read of shared data has to have a corresponding write that uses a lock". Lock meaning anything that results in the proper memory effects. I can sort of get that this

[go-nuts] lock for assigning to different elements of an array

No, but anything reading from that array which is not the original writer will have to coordinate via a lock or channel to ensure a proper happens before relationship exists. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from

Re: [go-nuts] lock for assigning to different elements of an array

On Wed, Aug 2, 2017 at 2:12 PM, rabiee via golang-nuts wrote: > > Do we need a lock for assigning to different elements of an array while > running parallel functions? No. Ian -- You received this message because you are subscribed to the Google Groups

[go-nuts] lock for assigning to different elements of an array

Hi All, Do we need a lock for assigning to different elements of an array while running parallel functions? For example is lock needed in the following code or not. var rm sync.Mutex var ts [2]stringfor i, s := range []string{"first", "second"} { i, s := i, s go func(){