On Thu, 3 Aug 2017, 8:45 am Dave Cheney <[email protected] wrote: > > > On Thu, 3 Aug 2017, 17:39 Dave Cheney <[email protected]> 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 <[email protected]> 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, <[email protected]> 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 <[email protected]> >>>> 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. >
Can you explain your reasoning here a little more, please? As far as I am aware it is always ok to write concurrently to different fields in the same struct and if that's not the case then I have some serious code review to do! > 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 <[email protected]>: >>>>> >>>>>> 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 [email protected]. >>>>>> 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 [email protected]. > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
