On Thu, 3 Aug 2017, 17:39 Dave Cheney <d...@cheney.net> 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 > get a chance to run before main exits. > > The second program doesn't have a data race as the waitgroup.done / wait > creates a happens before relationship between reader and writer. > > On Thu, 3 Aug 2017, 17:33 Henrik Johansson <dahankz...@gmail.com> wrote: > >> 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, <d...@cheney.net> 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 <dahankz...@gmail.com> wrote: >>> >>>> 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 itself concurrently writing to the same array. How can this >>>> be safe in light of https://golang.org/ref/mem#tmp_10 . I get that >>>> your comment about "happens before" comes in here if there were any readers >>>> but eventually there will be readers or we would never need to do this. If >>>> the main after some time wants to access these values is it enough to make >>>> sure the goroutines are done perhaps using a WaitGroup or do we have to use >>>> some other synchronisation to ensure the visibility of the data in the >>>> array? >>>> >>>> https://play.golang.org/p/8BfrPhyIEb >>>> >>>> Or is it needed to do something like this: >>>> >>>> https://play.golang.org/p/9QgTP5Dqc7 >>>> >>>> I mean aside from the poor form of sleeping like this, the idea is to >>>> simulate usage "at some point later in time". >>>> >>>> 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 from go routines like this even though it seems to be ok. >>>> >>>> Does this hold for slices as well as for arrays? >>>> >>> Yes, it is safe for multiple goroutines to write to different array elements, the same is true for slices as they are backed by an array
What about assignments to fields in structs? >>>> >>> Yes. Can several goroutines safely write to different fields in the same struct >>>> assuming they are word sized? >>>> >>> Yes, although they should also be naturally aligned. Does this hold for all architectures? >>>> >>> Some architectures have issues with atomic writes to values smaller than a word. Look for xor8 in the runtime source. Writing to adjacent memory locations will cause false sharing between CPU caches. This is a performance, not a correctness issue. >>>> I am sorry if I am still a bit unclear but I find it hard to ask >>>> properly when I am a bit unsure of the topic. :D >>>> >>>> >>>> >>>> tors 3 aug. 2017 kl 07:49 skrev Dave Cheney <d...@cheney.net>: >>>> >>>>> 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 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. >>>>> >>>> -- 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.
