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? What about assignments >>> to fields in structs? Can several goroutines safely write to different >>> fields in the same struct assuming they are word sized? Does this hold for >>> all architectures? >>> >>> 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.
