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)
> w
@rog Thanks! Three-value slice operator was a very nice hint.
The original intention was to implement a buffer-pool (pool of []byte)
without fragmenting the memory. But I was not sure if I was doing it right.
Seems now, assuming the pool consumers are polite goroutines, this can be a
good solut
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
operat
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 not
@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 "If
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 resu
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
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 bucket
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
@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 co
@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 gorouti
@ 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 a
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.
Y
18 matches
Mail list logo
