your assumption: "As long as two goroutines are not modifying the same item in an array, accessing it is safe." is not entirely correct, or is incomplete. Even when only one goroutine is writing to that item, and a different one or more are reading, you still got a race, and the race detector will flag it. E.g. with 10 million iterations: https://play.golang.org/p/bpUQEyZMMy4
On Sunday, 22 April 2018 16:20:40 UTC-4, Kaveh Shahbazian wrote: > > Thanks Silviu, > > Even when accessing the array directly in a concurrent manner, -race does > not complain: https://play.golang.org/p/l-c2aPeOGwF > > So, is this assumption correct? : As long as two goroutines are not > modifying the same item in an array, accessing it is safe. > > The initial intent was to implement a buffer pool; large arrays providing > fixed length slices of (for example) 4KB length - and if the length of a > message was above that, a slice would be allocated separately. > > On Sunday, April 22, 2018 at 6:15:04 PM UTC+4:30, Silviu Capota Mera wrote: >> >> Kaveh, for this particular circumstance, based on your playground >> snippet, that's why you got no race. >> >> As per the original 2013 race detector blog post, "Because of its design, >> the race detector can detect race conditions only when they are actually >> triggered by running code, which means it's important to run race-enabled >> binaries under realistic workloads." >> >> >> On Sunday, 22 April 2018 07:56:48 UTC-4, Kaveh Shahbazian wrote: >>> >>> @Silviu >>> >>> But no slice expansion is happening. >>> >>> On Sunday, April 22, 2018 at 5:41:11 AM UTC+4:30, Silviu Capota Mera >>> wrote: >>>> >>>> Hi Kaveh, >>>> >>>> Change the line: >>>> *ptr = append(*ptr, []byte(fmt.Sprint*f("%02d"*, k1))...) >>>> >>>> to >>>> *ptr = append(*ptr, []byte(fmt.Sprintf(*"%15d"*, k1))...) >>>> >>>> The buckets will overlap (more than 10 bytes) and you will get the race >>>> triggered in the detector >>>> >>>> Silviu >>>> >>>> >>>> On Saturday, 21 April 2018 12:40:04 UTC-4, Kaveh Shahbazian wrote: >>>>> >>>>> @Ankit That's what I thought. Yet the code is accessing the same >>>>> underlying array. That is the part that worries me and -race does not >>>>> complain. >>>>> >>>>> @Louki Still no complain from -race! >>>>> https://play.golang.org/p/dUt0QE63RDK >>>>> >>>>> On Saturday, April 21, 2018 at 7:01:25 PM UTC+4:30, Louki Sumirniy >>>>> wrote: >>>>>> >>>>>> Unless you pass pointers in Go, every time you hop in and out of a >>>>>> new scope any changes are discarded. This is why unless you type-bind >>>>>> with >>>>>> pointers you don't actually have an OOP method, as the function will not >>>>>> act upon the parent variable/structure. >>>>>> >>>>>> I think if you change your playground code to pass pointers into the >>>>>> goroutines you'll either see race detector or clobbering. >>>>>> >>>>>> On Saturday, 21 April 2018 16:30:22 UTC+3, Ankit Gupta wrote: >>>>>>> >>>>>>> @Kaveh >>>>>>> >>>>>>> Slices are values but they refer to the same back array location. >>>>>>> You have created localized v which is appended inside goroutine which >>>>>>> refer >>>>>>> to a location containing its own byte array of len=10. So, you are not >>>>>>> really referencing the same memory location as other v slice in the >>>>>>> goroutine. You will be affected if you remove k,v:=k,v or append more >>>>>>> than >>>>>>> 10 bytes to v inside goroutine which will take up space on next slice's >>>>>>> bytes. >>>>>>> >>>>>>> On Saturday, April 21, 2018 at 2:30:53 PM UTC+5:30, Kaveh Shahbazian >>>>>>> wrote: >>>>>>>> >>>>>>>> @ Louki Sumirniy >>>>>>>> Slices are values AFAIK. There is no passby pointer. >>>>>>>> >>>>>>>> And the point is, race detector does not flag anything: >>>>>>>> https://play.golang.org/p/NC8mBwS1-0P >>>>>>>> >>>>>>> -- 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.
