While not quite the same problem, this post describes something similar in
concept, "banking strings" in a single large byte slice to avoid GC
pressures.
https://syslog.ravelin.com/whats-all-that-memory-for-e89522e1c2c6
On Friday, April 20, 2018 at 11:26:08 PM UTC-4, Kaveh Shahbazian wrote:
>
Final code is here: https://github.com/dc0d/bufferpool
I hope I got it right!
On Monday, April 23, 2018 at 9:48:20 PM UTC+4:30, Kaveh Shahbazian wrote:
>
> @rog Thanks! Three-value slice operator was a very nice hint.
>
> The original intention was to implement a buffer-pool (pool of []byte)
>
You original example has a problem that others have pointed out because
it's possible for one goroutine to step on the part of the backing array used
by others. In principle though your technique looks OK to me as long
as you prevent that happening, for example by using the three-value slice
Also -race does not complain about this:
https://play.golang.org/p/IeA4npcemf5
On Monday, April 23, 2018 at 10:51:05 AM UTC+4:30, Kaveh Shahbazian wrote:
>
> @Silviu The code is mutating same item from two goroutines. While the
> original target is to create a buffer pool that their items is
@Silviu The code is mutating same item from two goroutines. While the
original target is to create a buffer pool that their items is not being
mutated from two goroutines - actually they can not do that because at a
specific time only one goroutine has access to one buffer.
@Tamas Regarding
There does still need to be a mutex for reads on an element that is being
written to. It's a minor edge case but it could cause a serious problem
when it hoppens.
On Monday, 23 April 2018 08:36:38 UTC+3, Tamás Gulácsi wrote:
>
> If there's no uncoordinated write and read/write of the same slot,
If there's no uncoordinated write and read/write of the same slot, then it's
race-free.
Only reads does not need coordination.
I'm using a pattern alike: allocate a slice for the results, start the
goroutines, each writing into it's own slot, then wait all of them to complete,
and use the
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
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
@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
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
@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
@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
@ 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
I am pretty sure that you will run into problems with this. On one hand
passing pointers could lead to a write after a read, and on the other hand
with pass by value you could get an out of date value and then stomp over
another process write. I'm pretty sure the race detector will flag this.
16 matches
Mail list logo
