Yes, that is indeed a race: https://play.golang.org/p/JH6dx9UNxm
But it only happens when there are multiple cases where:
len(stem) + len(tail) < cap(stem)
race-detector detects unsynchronized write-then-(write|read)-s to a memory
location
For example when there is only one case for "len(stem) + len(tail) <
cap(stem)" -- it will work, because the unused buffer in "stem" is written,
but it is read from the same goroutine.
Although, it probably should throw a race warning all the time
i.e. implementation-wise it probably should do:
func append(xs []int, data ...int) []int {
if race.Enabled && len(xs) < cap(xs) {
xs[len(xs)] = 0
}
// actual append implementation
}
On Monday, 6 November 2017 02:44:11 UTC+2, kortschak wrote:
>
> Say I have a []T that I want to use as a common stem that has a tail
> appended onto it, used concurrently, for example:
>
> for i := 0; i < N; i++ {
> tail := makeTail(i) // Returns a []T.
> wg.Add(1)
> go func() {
> defer wg.Done()
> a := append(stem, tail...)
> fn(a) // Does something expensive with a []T.
> }()
> }
> wg.Wait()
>
> This looks racy to me, since each append can potentially clobber
> elements in stem between len(stem) and cap(stem). Am I being paranoid
> or should I write this append as append(stem[:len(stem):len(stem)],
> tail...)?
>
> I have not been able to get the race detector to complain about this,
> even if I make len << cap.
>
> thanks
>
--
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.
