On Fri, 1 Feb 2019, 2:56 pm Robert Engels <reng...@ix.netcom.com wrote: > 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 replying to Dave Cheney's assertion. Perhaps he knows something we don't... > > On Feb 1, 2019, at 8:52 AM, roger peppe <rogpe...@gmail.com> wrote: > > > > On Thu, 3 Aug 2017, 8:45 am Dave Cheney <d...@cheney.net wrote: > >> >> >> 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. >> > > 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 <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. >> > -- > 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.
