镜像包并发操作引发异常行为

你在学习Golang相关的知识吗？本文《镜像包并发操作引发异常行为》，主要介绍的内容就涉及到，如果你想提升自己的开发能力，就不要错过这篇文章，大家要知道编程理论基础和实战操作都是不可或缺的哦！

我尝试运行的程序是一维细胞自动化图像生成器，它需要足够强大才能处理数百万个单个细胞的超大型模拟，因此图像生成过程的多线程是必要的。我之所以选择 go，是因为 go 例程将使 cpu 的工作划分问题变得更加容易和高效。现在，因为用单独的 go 例程编写每个单元格的性能根本不会很高，所以我决定创建一个调用图像对象并负责生成整行单元格的函数。该函数引用一个 2d 数组对象，其中包含要绘制的所有单元格的位切片（请参阅此）数组，因此存在许多循环，但这对于当前的问题并不重要。程序应该做的就是简单地读取所有单独的位，并将一个正方形写入图像矩形的正确位置，表示单元格的存在（基于表示正方形边长的变量 psize）。这是该函数...

func renderrow(wg *sync.waitgroup, img *image.rgba, i int, psize int) {
    defer wg.done()
    var lpc = 0
    for j := 0; j < 64; j++ {
        for k := range sim[i] {
            for l := lpc * psize; l <= (lpc*psize)+psize; l++ {
                for m := i * psize; m <= (i*psize)+psize; m++ {
                    if getbit(sim[i][k], j) == 1 {
                        img.set(l, m, black)
                    } else {
                        img.set(l, m, white)
                    }
                }
            }
            lpc++
        }
    }
}

现在我很高兴地说，当在一个线程上顺序运行时，此函数的执行效果与预期一致。这是非并行函数调用（忽略等待组）

img = image.newrgba(image.rectangle{min: upleft, max: lowright})

for i := range sim {
    renderrow(&wg, img, i, psize)
}

f, _ := os.create("export/image.png")
_ = png.encode(f, img)

img = image.newrgba(image.rectangle{min: upleft, max: lowright})

for i := range sim {
    go renderrow(&wg, img, i, psize) // todo make multithreaded again
}

wg.wait()

f, _ := os.create("export/image.png")
_ = png.encode(f, img)

现在这两个各自实现的输出是什么样的？ 使用这些起始条件 {0, 1, 0, 1, 0, 0, 1, 0, 1, 1, 0, 1, 0, 1, 1, 0, 1, 1, 1, 1, 0, 1, 1, 0, 1, 1, 0, 1, 1, 0, 0, 1, 0, 1, 1, 1, 0, 1, 1, 0, 0, 1, 1, 0, 0, 1, 1, 1, 1, 0, 1, 0, 1, 0, 0, 0, 1, 1, 1, 1, 1, 0, 0, 1} 和 11 的演化空间 (psize 2)。我们将其作为单线程实现的输出...

现在，如果放大该图像，您会发现所有正方形在垂直和水平方向上间隔均匀，没有异常。不过现在让我们看一下并发输出。

这个版本似乎有一些异常现象，许多行都被缩小了，许多地方都存在单独的像素错误，尽管它正确地遵循了模拟的一般模式，但视觉上肯定不令人愉悦。当我调查这个问题时，我寻找与并发相关的问题，所以我认为图像包中像素数组的动态分配可能会导致某种冲突，所以我调查了 img.set() ，它看起来像这...

func (p *nrgba) set(x, y int, c color.color) {
    if !(point{x, y}.in(p.rect)) {
        return
    }
    i := p.pixoffset(x, y)
    c1 := color.nrgbamodel.convert(c).(color.nrgba)
    s := p.pix[i : i+4 : i+4] // small cap improves performance, see https://golang.org/issue/27857
    s[0] = c1.r
    s[1] = c1.g
    s[2] = c1.b
    s[3] = c1.a
}

但是当我看到这个时，它似乎没有任何意义。看来 img.pix 元素将所有像素数据存储在表示颜色的连续一维整数数组中，但如果传递给它的 (x,y) 元素已在中找到，则 .set() 函数会立即返回.pix 切片。但更奇怪的是，似乎是某种隐式赋值（在 go 中从未见过），其中 .pix 切片的 4 个元素被取出来表示单个像素的颜色，并赋值给 s。最奇怪的部分是 s、c1 和 i 永远不会再次被引用、返回或存储在内存中，只是被扔进垃圾回收。但不知怎的，这个函数似乎是按顺序工作的，所以我决定让它做它的事情，看看并发和非并发实现之间的 .pix 切片有什么区别。

现在这是四个粘贴箱的链接，它们包含 2 个单独试验的 img.pix 对象数据，每一行都属于单个像素的颜色，从每个图像的左上角开始向下移动。进行两次试验的原因是为了验证单线程方法的一致性，该方法看起来是一致的，但正如您可以通过访问 diffchecker.com 这样的网站观察到，多线程测试都显示了它们与单线程输出之间的差异。

多线程测试1

单线程测试1

多线程测试2

单线程测试2

现在我将分享一些对此数据的观察。

• 不同的多线程和单线程测试之间存在差异，且存在不同程度的差异
• 单线程和多线程之间的添加和删除数量相同，这意味着所有数据都存在，只是顺序错误。

// NewRGBA returns a new RGBA image with the given bounds.
func NewRGBA(r Rectangle) *RGBA {
    return &RGBA{
        Pix:    make([]uint8, pixelBufferLength(4, r, "RGBA")),
        Stride: 4 * r.Dx(),
        Rect:   r,
    }
}

总而言之，我真的不知道发生了什么。当多个 go 例程访问同一个切片时，图像包似乎会出现一些奇怪的行为，但由于切片的索引理论上是绝对的（意味着每个变量都是唯一的），因此不应该有任何排序问题。我能想到的唯一可能的问题是，尽管切片是以这种方式定义的，但它仍以某种方式通过该设置函数调整大小，或者至少四处移动导致碰撞。非常感谢任何帮助找出问题所在或任何有关可能导致问题的理论。干杯！

正确答案

上面的代码会产生许多竞争冲突，这些冲突是由于 go 例程尝试写入 .Pix 对象中的相同像素坐标而引起的。该修复位于 renderRow 函数内，其中由于 <= 而不是“<”，当前像素的宽度和高度的计算在每次迭代中重叠。这个故事的寓意是使用 -race 来查找冲突并始终查找同一变量的覆盖或并发读取。感谢@rustyx。

本篇关于《镜像包并发操作引发异常行为》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于Golang的相关知识，请关注golang学习网公众号！