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.
