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 <[email protected]> wrote: > > > >> 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. -- 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.
